ugrás a tartalomhoz

Túl bonyolult

Hidvégi Gábor · Május. 25. (P), 22.21
Ha egy egyéves kisgyereknek adnak egy kristályvázát, akkor előbb-utóbb, amikor elveszti iránta az érdeklődését, szétnyitja a kezét, a váza leesik és összetörik. Ez azért van, mert még nem érti a gravitációt, így nem látja át a tettének a következményeit.

Izgalmas időket élünk. A 2018 január elején napvilágot látott processzorhibák megrázták a számítástechnológiai világot, 2017 az informatikai betörések éve volt, sohasem látott mennyiségben hatoltak be rendszerekbe, ahonnan adatokat vittek el vagy egy zombihálózat részévé tették. Mindezek természetesen nem véletlenül, előzmények nélkül történtek, és ha a nagy képet nézzük, talán nyilvánvaló, hogy ha így folytatjuk tovább, a helyzet csak rosszabb lesz.

Hardver

Ma egy átlagos processzorban legalább egymilliárd tranzisztor található, a komolyabbakban ennek a többszöröse, ami a nagy számok törvényei alapján biztosan nem lesz tökéletes. Egy véletlenszerűen kiválasztott Intel Core i7-es CPU dokumentációjában például két oldalnyi, a gyártó által ismert és javítatlan hiba található, amelyek instabilitáshoz, helytelen értékek visszaadásához és nem konzisztens működéshez vezethetnek. Ezek természetesen nem újkeletű dolgok, Theo de Raadt, a biztonságot a legfontosabb szempontnak tartó OpenBSD operációs rendszer vezető fejlesztője már 2007-ben, az akkor aktuális Core 2 processzorokról írta, hogy legalább húsz-harminc olyan buggal rendelkeznek, amit szoftveresen nem lehet javítani.

A védekezés ezek ellen nehéz vagy lehetetlen, a CERT-nél eredetileg a hardverek cseréjét ajánlották, aztán ezen valamiért enyhítettek (már csak szoftverfrissítést említenek, ami a Spectre esetében biztosan kevés). A Meltdown elvileg kikerülhető az operációs rendszer módosításával, de ez 5-30, bizonyos esetekben akár ötven százalékos teljesítményvesztéssel jár, azzal arányosan, hogy az adott szoftver milyen gyakran fordul a kernelhez.

A biztonsággal foglalkozó szakember, Bruce Schneier szerint 2018 a hardveres hibák éve lesz, és ebben valószínűleg igaza van. Az egyre integráltabb elektronikai alkatrészek egyes moduljai és az azok közti kommunikáció egyre komplexebb, és készítőik egyszerűen nem látják át az összes lehetséges kombinációt. Májusban újabb sérülékenységet lepleztek le, de még legalább hat várható a közeljövőben, amelyek közül az egyik sebezhetőség várhatóan azért lesz nagy hatású, mert virtuális gépekből lehet elérni a gazda erőforrásait, azaz a "felhő" szolgáltatók lesznek nagy bajban, valószínűleg jelentős teljesítménycsökkenés várható a rendszereikben.

Aki figyeli a számítástechnikai eszközök fejlődését, feltűnhetett, hogy a processzorok az utóbbi tíz évben a korábbiakhoz képest alig fejlődtek, átlagosan öt százalékkal voltak gyorsabbak az előző generációhoz képest. Ez nem csak az Intel dominálta x86-os, hanem az ARM architektúrára igaz, mert bár ott az elején nagy volt a lendület, 2014 óta nem volt igazán nagy áttörés a teljesítmény/fogyasztás fronton. A mobiltelefongyártók jobb híján csak azzal tudnak zsonglőrködni, hogy egyre nagyobb akkumulátorokat zsúfolnak a készülékekbe, ami csak egy ideig jelent megoldást, mert az energiatárolás elvei nem változtak az utóbbi húsz évben, és nincs is remény rá, hogy javulni fog a hatékonyság.

A fentiek alapján alapján várható, hogy a hardverek teljesítménye legjobb esetben stagnálni fog, de jó eséllyel érezhetően vissza is esik.

Szoftver

Tehát a számítógépek lassulása várható, de átlagfelhasználókat ez kevésbé érinti, hisz a legtöbb szoftver az idő kilencvenkilenc százalékában arra vár, hogy történjen egy billentyűleütés vagy egérkattintás, aztán pártized másodperc alatt végez a feladattal. A szerverek már más kategóriába esnek, ahol sok az IO, észrevehető a változás, mérések szerint a PostgreSQL 10-20%-kal reagál lassabban.

Erős növekedés tapasztalható minden évben az informatikai betörésekből származó "ellopott" adatok számában, 2016-ban még "csak" párszáz milliós nagyságrendben vittek mindent, 2017-ben csak a River City Media nevű hirdetőcégtől 1,3 milliárd rekordos adatbázis került illetéktelenek kezébe, de az Equifaxtól lemásolt kétszázmilliós, különösen érzékeny adatokat tartalmazó adatbázis volt az igazán nagy fogás.

Persze évtizedes múlttal rendelkező szoftvercégek is követnek el amatőr hibákat, az Apple egyik fórumán osztotta meg az egyik gyanútlan felhasználó, hogyan lehet az operációs rendszer gyökér felhasználójával jelszó nélkül belépni (kétszer kell lenyomni az Entert).

Szivárgó absztrakciók

Az embert az állatvilágból többek között az absztrakció képessége emeli ki, aminek a segítségével el tudunk vonatkoztatni bizonyos dolgoktól, és csak a lényeggel foglalkozunk. Ennek köszönhetjük például, hogy létezik a matematika és a számítógépek, az informatika pedig nem is működne elvonatkoztatás nélkül. Joel Spolsky, a Stack Overflow alkotója 2002-ben fogalmazta meg a szivárgó absztrakciók törvényét, amelynek lényege, hogy minden absztrakció egy bizonyos fokig szivárog, azaz a valóság előre nem látható következményei problémákat okoznak.

A számítástechnikában az elvonatkoztatásnak megfigyelésem szerint még egy hatása van: minden absztrakció a program futását lassítja; erre a legjobb példa a függvényhívás, ahol az elején – többek között – le kell foglalni egy memóriaterületet a helyi változóknak, majd a végén fel kell szabadítani. Ezt akkor lehet észrevenni, ha egy ciklusban, sokszor futtatjuk a függvényt, mérhetően több idő kell neki, mintha a függvénytörzset másolás-beillesztés módon n-szer egymás után tennénk.

A Spectre típusú sérülékenységek is egy absztrakciónak köszönhetőek; ma sok szoftver és programozási nyelv C/C++ alapokon nyugszik, de a C-t a '70-es években olyan platformra tervezték, ahol a fizikai hardvert lehetett közvetlenül elérni a segítségével. Később viszont a processzorok sokkal gyorsabbak lettek, mint a RAM, ezért többszintű gyorstárat vezettek be, ami a program szemszögéből úgy látszik, mintha maga a memória lenne, viszont a háttérben a komplexitást extra hardverek kezelik. Ezek a cache-ek megosztottak, azaz a különböző programszálak elérhetik egymás memóriaterületeit, és ezzel meg is van a baj. A gépi kódra fordító programok is rendkívül összetettek, azért, hogy minél optimálisabb futást biztosítsanak, az LLVM forrása például kétmillió soros.

Megoldás

John McAfee, akinek az antivírus szoftvere ismerős lehet az olvasó számára, fogalmazta meg a következő biztonsági sejtést: "Minden általunk kitalált logikai struktúra potenciálisan hack-elhető, és az minél összetettebb, annál biztosabb, hogy a feltörés meg fog történni."

A fentiek alapján nyilvánvaló, hogy minden probléma okozója a túlzott bonyolultság, mind hardver-, mind pedig szoftverszinten. Annyira sokféle esemény történhet, amit a készítőik egyszerűen nem látnak át, azaz az intelligenciájuk alacsonyabb, mint ami az átlátáshoz és a megoldáshoz szükséges lenne (így érthetővé válhat az írás első mondata). Ezt többféleképp is lehetne orvosolni:
  • az IQ növelésével – mivel egy új generáció 20-25 év, jónéhány évtizeden belül nem várható számottevő javulás
  • az eszköztár javításával – ezek újabb absztrakciók, amik szivárognak, azaz így csak elodázzuk, másra hárítjuk a felelősséget
  • a komplexitást csökkentjük.
Ami a legegyszerűbb és leghatékonyabb, az az utolsó, azaz át kell gondolni, mi az, amire nincs szükség, és azt egyszerűen ki kell dobni.

Egy szoftver sosincs kész – bár ma ez egy általánosan elfogadott, de az egyik legkártékonyabb elv, ami a felhasználók életét mérgezi. Mindenhova tömik be az újabbnál újabb szolgáltatásokat, és aztán csodálkoznak, ha a rendszert feltörik. Minél kevesebbet tud egy program, annál biztonságosabb lehet, mert a kényelem-sebesség-featúrák trió egy tengelyen helyezkedik el a biztonsággal, és az egyiket mindig csak a másik kárára lehet növelni.

A cél elérésében nem segít minket a kapitalizmus és a szabadverseny, ezek miatt mindenki azt gondolja, hogy minél több mindent pakolunk egy hardverbe vagy szoftverbe, annál jobban fogják venni, de ez csak egy bizonyos szintig igaz, addig, amíg jobban kifizetődik így dolgozni, mint valamit egyszerűre és biztonságosra elkészíteni. De a hardverek lassulásával talán elindul egy pozitív folyamat, ahol minden csak épp annyit tud, épp annyi absztrakcióval rendelkezik, amennyire szükség van, és marketingértéke lesz annak, hogy "a mi termékünk butább, de biztonságosabb, mint a konkurenciáé". Ez viszont a jelenlegi fejlesztési trendeknek eléggé szembemegy, azaz meglehetősen fájdalmas lehet az egyszeri programozó számára.
 
1

minden absztrakció a program

BlaZe · Május. 26. (Szo), 00.09
minden absztrakció a program futását lassítja; erre a legjobb példa a függvényhívás, ahol az elején – többek között – le kell foglalni egy memóriaterületet a helyi változóknak, majd a végén fel kell szabadítani.
Ez nem teljesen így működik. Nem kell memóriát lefoglalni, a paraméterek (már ez is csak akkor, ha sok van) és a lokális változók a stacken jönnek létre. Azért lassabb a függvényhívás, mert el kell menteni a hívó címét (hogy tudja a gép hová kell majd visszatérni), át kell állítani 1-2 regisztert, ugrani kell, majd vissza kell térni. Ez pedig nagy mennyiségben már mérhető. Cserébe a fordítók inline-olják a függvényeket, ahol van értelme.

Ezek a cache-ek megosztottak, azaz a különböző programszálak elérhetik egymás memóriaterületeit, és ezzel meg is van a baj.
Ebben mi a baj? Pont az a lényege a szálaknak, hogy megosztott memóriaterületet használnak. Vagy arra gondolsz, hogy 2 különböző process 2 szála simán látja egymás adatait, mert ugyanazon a magon futnak? Csak mert ez nem igaz. A Spectre is side-channel attack, nem arról van szó, hogy csak úgy olvasgatják egymás memóriaterületét. Nehéz is lenne, mivel virtuális címekkel címzünk.

Tudsz mondani konkrét példát, hogy mire szeretne a cikk kilyukadni? Fura zárszó, hogy reménykedjünk a gépek lassulásában. Ez senkinek sem érdeke. Ha a cikkben kritizált "absztrakciók" eltűnnének, te is elveszítenéd a munkádat, ugyanis egy örökkévalóság lenne pl CPU cache-ek nélkül egy weboldal renderelése.
4

a lokális változók a stacken

Hidvégi Gábor · Május. 29. (K), 08.49
a lokális változók a stacken jönnek létre
A stack-en belül is kell foglalni és felszabadítani.

A Spectre is side-channel attack, nem arról van szó, hogy csak úgy olvasgatják egymás memóriaterületét. Nehéz is lenne, mivel virtuális címekkel címzünk.
A Spectre-nek pont ez a vége, hogy ha lassan is, de ki tudod olvasni a számítógép teljes memóriáját. Az, hogy nem pontosan fogalmaztam, nem változtat a tényeken.

Tudsz mondani konkrét példát, hogy mire szeretne a cikk kilyukadni? Fura zárszó, hogy reménykedjünk a gépek lassulásában. Ez senkinek sem érdeke. Ha a cikkben kritizált "absztrakciók" eltűnnének
Az absztrakcióknak nem eltűnniük kell, hanem szerintem célszerű a számukat a minimálisra csökkenteni. A gépek lassulása szerintem nagyon fontos lenne, ugyanis enélkül csak az absztrakciók száma és a bloat növekszik.

A szoftver olyan, mint a gáz, mindig kitölti a rendelkezésre álló teret. Erre a legaktuálisabb példa volt, amikor bevezették a böngészők többszálú működését, rövid ideig észrevehető volt, hogy az oldalak gyorsabban töltődtek be, de a fejlesztők elkezdték kihasználni ezt a lehetőséget, és ma már nem nehéz megfektetni egy akárhány magos gépet egy jól elkészített website-tal, például webworkerekben futó bitcoin bányászattal.
5

A stack-en belül is kell

BlaZe · Május. 29. (K), 18.59
A stack-en belül is kell foglalni és felszabadítani.
Igen, létezik az a fogalom, hogy stack allocation, ez a stack pointer módosítását jelenti. Ezen kívül a stack mindig a cache-ben van. Összehasonlíthatatlan a teljesítménye egy heap allocationnel, amit a cikk sugall. Gyakorlatilag kimérhetetlen költsége van, elnyomják azoknak a költségei amit írtam. De még azok is igen alacsonyak egy mai rendszeren. Teljesen értelmetlen ezen rugózni.

Mindezektől függetlenül természetesen lehet értelme az inline-olásnak fastpathon. De a fordítók sem inline-olnak mindent, amit lehetséges lenne, mert nagyon hatékonytalan lenne. Valójában a függvényhívás inkább arra jó példa, hogy az értelmes absztrakciók jótékony hatással lehetnek a teljesítményre.

A Spectre-nek pont ez a vége, hogy ha lassan is, de ki tudod olvasni a számítógép teljes memóriáját. Az, hogy nem pontosan fogalmaztam, nem változtat a tényeken.
Absztrakciókról beszélsz, és egy implementációs hibát hozol példának. Ezért nincs értelme. Amellett, hogy egész mást sugallt amit írtál, mint ami a valóság.

A gépek lassulása szerintem nagyon fontos lenne, ugyanis enélkül csak az absztrakciók száma és a bloat növekszik.
A számítógépek teljesítményének és az absztrakciók számának a növekedésével nem csak a bloat növekszik, hanem a megoldható feladat komplexitása is. Nem a móka kedvéért növekszik az absztrakciók száma, hanem mert egyre komolyabb feladatokat ellátó rendszerek születnek.

Nem a gépeknek kellene lassulnia, hanem a programozóknak kéne megtanuljanak normálisan programot írni. Amíg egyetemről kijönnek úgy emberek, hogy nem értik pl egy hashtable (vagy akár egy láncolt lista!) működését, vagy lefagynak egy maradékos osztástól, addig nem a fejlődő hardware-ben kell keresni az okokat. Aki a mai hardware-eken rossz kódot ír, az a lassabb hardware-eken is rossz kódot írna. Csak még több lenne a használhatatlan rendszer.
2

Valahogy nem érezni, hogy

inf3rno · Május. 26. (Szo), 01.26
Valahogy nem érezni, hogy megállt volna a növekedés CPU sebességben vagy aksi kapacitásban. Gondolom ez olyan, mint a világvége, ha idén nem jön, majd jövőre.
3

PHP Depend

T.G · Május. 26. (Szo), 12.28
A téma címe kapcsán egy apró kiegészítést tennék. A bonyolultság csökkentése az kifejezetten támogatandó folyamat. PHP-ben az egyik hasznos segédeszköz a PHP Depend. Erről már volt szó a Weblabor-on régebben. Illetve ugyanitt még több hasznos segédeszköz is található.
6

Videó

Hidvégi Gábor · Jún. 22. (P), 12.20
Érdemes megnézni ezt a videót a komplexitás témakörében, bár még csak az elején tartok, olyan csemegék vannak benne, hogy például az USB Type C vagy a Lightning-DVI kábelekben is van processzor, és nemsokára az lesz a kivételes, ha egy alkatrészben nincs valamilyen számítógép.

Az előadás arról szól, hogy a biztonságra milyen hatással van a növekvő bonyolultság.