A Windows 7 / Windows Server 2008 Meldown patch nagyobb problémát csinált, mint hasznot

Titkosítás, biztonság, privát szféra

A Meltdown sebezhetőség arról szólt, hogy privilégium nélküli alkalmazások képesek lehettek olvasni a kernel memóriát nem túl tempós, másodpercenkénti megabájt sebességgel. Jött a Microsoft és megjavította. Az eredmény: kijavították a problémát, ami helyett most már bármely processz képes a teljes memóriatartalmat olvasni másodpercenkénti gigabájt sebességgel és ha ez nem elég, feltehetően írni is ...

Részletek itt.

( trey | 2018. 03. 28., sze – 12:53 )

tl;dr:

- Aki nem patchelte meg januárban vagy februárban a Meltdown-t, azt nem érinti.

- Aki megpatchelte akkor, de már feltette a 2018-03 sec. rollup-ot, az nem érintett.

- Aki patchelt januárban és/vagy februárban, de nem tette még fel a 2018-03 sec. rollup-ot, az érintett.

--
trey @ gépház

Én most nem konkrétan a Meltdownra gondoltam, hanem úgy általában. Pl. azt mondta, hogy a sebességigényes részeket assemblyben kéne megírni.
Valamelyik IRC csatornán hallottam 2004-ben, hogy amikor BoyC a Crystal Vision-t írta, akkor csinált C kódot és ASM-et is és a C fordító kisebb és gyorsabb kódot generált, mint amit ő hozott ki ASM-ben. Namármost, ha már a demoscenerek is azt mondják már vagy egy másfél évtizede, hogy nem nagyon van már értelme ASM-ben optimalizálni, akkor az már csak mond valamit.

Biztos nem értett hozzá eléggé :-). Egyébként meg azt is lehet csinálni, hogy csinálsz C-t, lefordítod ASM-re és amit kapsz, azt még kézzel optimalizálod. Csak gyorsabb lehet, lassabb nem.

A tétel annyiból is megállja a helyét, hogy ő azért tudott olyan C-t írni, mert tudja hogy mutat ASM-ben. Aki nem tudja, annak a C kódja sokszorosan gyengébb lesz. És ez nem csak C-re igaz, de még a managelt nyelvekre is.

> Csak gyorsabb lehet, lassabb nem.

Fatális tévedés, lassabb is lehet. A fordító olyan dolgokat tart számon, ami a CPU-nak fontos, mi fér még a csőbe, mit milyen sorrendben fog végrehajtani és még lehetne sorolni. Nyilván, ahogy egy algoritmus is képes arra, hogy ez alapján rakjon össze kódot, az ember is képes lehet rá, de sokkal lassabban fogja ezt végiggondolni és ez alapján ASM kódot írni.

> A tétel annyiból is megállja a helyét, hogy ő azért tudott olyan C-t írni, mert tudja hogy mutat ASM-ben. Aki nem tudja, annak a C kódja sokszorosan gyengébb lesz.

És aki nem tudja, hogy hogy néz majd ki a C kódja ASM-ben, az szerinted mennyi eséllyel fog jó ASM kódot írni? :)

Lehet ezt is csinálni, de rengeteg hátrányt kapunk cserébe azért az usque pár század százaléknyi - vagy még annál is kisebb - gyorsulásért, többek között a fejlesztési idő extrém megnövekedését és a hordozhatóság elvesztését. Ma egy jól megírt C kód a megfelelő optimalizációkkal fordítva nemcsak, hogy bőven elég gyors lesz, de az esetek elsöprő többségében gyorsabb és kisebb lesz, mintha ember írja az ASM kódot.

Na jó, de ha meg már tud olyan C kódot írni, akkor meg minek? Ne érts félre, nagyon is fontos, hogy az ember tudjon assemblyben gondolkodni és programozni, de hacsak nem fordítót ír, akkor inkább azért, hogy tudjon jó, a CPU számára emészthető kódot írni, mintsem, hogy ő maga írja meg az ASM kódot. Ha rossz vagy lassú az algoritmus, akkor az ASM-ben is rossz vagy lassú lesz. Jobb algoritmussal többet tudsz nyerni, mint pár órajel megspórolásával.

Igen, a programozási nyelv kérdése azután jön (fontosságban, tanulási sorrendben nem feltétlen), hogy az algoritmusok skálázódását már értjük. Ez tiszta sor szerintem is. Meg az is, hogy a programok kódjának 95%-át nem érdemes ASM-ben írni, vagy megnézni, hogy mire fordít a gép.

Viszont én már láttam olyat éles projektben, hogy senki nem nézte meg, hogy mire fordul a kód, és az mit jelent az adott vason. 40%-ot sikerült fognom egy kritikus algoritmuson. Semmi ördöngősség nem volt benne, csak annyi, hogy én belegondolok abba is, hogy pontosan mit fog csinálni a gép. Pontosan azért, mert diákkoromban hobbiból eltöltöttem pár hetet is 1-2 függvénnyel adatlap és kockás papír szerint optimalizálva, és mérve az eredményt (első generációs Pentiumon stopperrel visszaosztva utolsó órajelig el tudtam számolni az idővel). Ehhez hasonló élményt ad, amikor időzítéskritikus kommunikációt írsz mikrovezérlőre szoftveresen órajeleket számlálva :-). Ha ezen végigmenne minden programozó, akkor jobb programokat tudnának írni.

Hát ha 40%-ot tudtál rajta fogni ASM-ben, akkor azon C-ben is tudtál volna majdnem, vagy akár ugyanannyit. Kivéve persze, ha az adott CPU valami nagyon kis teljesítményű cucc, pl. mikrokontroller volt, ha már megemlítetted a mikrokontrollerre írt időzítéskritikus kommunikációt. Az egy másik világ, ott nagyon is van létjogosultsága az ASM-nek. Mindig meg kell nézni, hogy mi a bottleneck és azon segíteni. Ha lehet. Nekem az LPT-s 1541 emulátoromban a fastloadereknél a bottleneck a közel 1 us-os ISA access latency volt, azon szoftverből akkor sem lehetett segíteni, ha tótágast állok a C128-on; pedig elhiheted, ott én is megpróbáltam ASM-ből időzíteni, meg optimalizálni, de amikor a mérések után kiderült, hogy a futásidő 95-96%-át az LPT-hez történő hozzáférés, 2-3%-át meg a getchar() eszi meg (azaz kb. 3 sor a ~3600-ból), akkor feladtam. Ezen max. hardware-esen lehet segíteni, de ez már off.

Bocs, félreérthetően írtam: C-ben fogtam 40%-ot, de azért mert tudtam mire fordul, és azt mennyi idő végrehajtani. Aki ezt nem tudja, az lassabb kódot fog írni, a fordítónak meg esélye sem lesz kioptimalizálni, mert azt úgy nem is lehet. Ezért félrevezető az a mantra, hogy majd a fordító megoldja. Magától nem oldja meg.

Ja, értem. Így már oké a dolog. Én nem nyomtam semmi mantrát, főleg nem azt, hogy a fordító megoldja helyettem (herótom van attól, amikor az eszköz akarja megoldani a problémát helyettem), én konkrétan azt állítottam, hogy manapság kézzel optimalizálni ASM-ben többnyire értelmetlen. Kivétel persze van, de hajbazer általánosságban vetette fel ezt a megközelítést és én erre reflektáltam.

( YleGreg | 2018. 03. 28., sze – 13:56 )

Sírok, zokogok. Ez olyan abszurd, hogy erről ez jutott az eszembe:

Firefly (egy elkaszált pedig qrva jó western-scifi sorozatban hangzik el):

Wash: „Médium? Ez úgy hangzik, mint valami science fiction.”
Zoe: „Drágám, egy ûrhajóban élünk.”
Wash: „Hogy jön ez ide?”

( http://firefly.hu/mutat.php?cid=2 )

Szóval valaki ébresszen fel, és adjon egy légyszi egy piros pirulát hogy kijussak innen, meg egy kéket a csajok miatt fejfájásra.

Most komolyan, hogy építsen az ember komolyan vehető infrastruktúrát olyan folyóhomokból amit néha még a gyártó is oldalbavizel?

( peta v | 2018. 03. 28., sze – 20:41 )

Nem flame miatt (tuti csak én nem járok a megfelelő oldalakra), de találkozhattam volna olyan hírrel, hogy meltdown/spectre miatt loptak el adatot, vagy történt bármilyen incidens?

( freeoli v | 2018. 03. 29., cs – 06:51 )

Engem az érdekelne, hogy ha telepítve van már a bios-ba az updated microcode és az fut a cpu-ban, akkor is betöltődik a patch és akkor is fenn áll ez a hiba? Sajnos nem találtam az első oldalon infót.

( ncc1701 | 2018. 03. 29., cs – 12:21 )

Én akkor hagytam abba a frissítések telepítését, mikor ezek a túlhypeolt hibák kiderültek. És utána kiderült, h rossz a patch. És most kiderült, h a hibás pecset javító pecs is hibás. Vagy ez már az azt javító peccs?
Asszem kivárok. :)

( hnsz2002 v | 2018. 03. 30., p – 10:29 )

Egyre jobban hajlok már én is arra, hogy ha valami megy, tök mindegy, hogy windows, linux, android vagy miabánat, hagyni kell úgy ahogy van, nem kell bántani, "frissíteni", mert a frissítéssel csak lassabb lesz, és semmi esetre sem jobb, legjobb esetben nem rosszabb.
--
"Sose a gép a hülye."

tegnap az ubuntuba megérkezett az intel-microcode 3.20180312.0~ubuntu17.10.1
akkor nem indítottam újra, mert minek.

ma nem indult el a gép, azt mondta 'BUG! watchdog...' valami elszállt, egyesével elkezdtem leszedni amit tegnap feltettem, és láss csodát intel-microcode eltávolítás után elindult minden..

most kit kellene megverni? az intel, v. az ubuntu csapatot? :)
avagy mindenkit?