ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
A Windows 7 / Windows Server 2008 Meldown patch nagyobb problémát csinált, mint hasznot
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.
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélInformációKövess minket! |
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
És akinek fogalma nincsen, hogy patchelt-e, vagy sem és a rendszere most éppen melyik stációban ketyeg, az mit csináljon? :)
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Hogy melyik rollup van fenn / nincs fenn, az 3 kattintással ellenőrizhető a Windows Update -> "View update history" alatt.
https://flic.kr/p/25vDMeL
--
trey @ gépház
És itt pontosan melyik a pecs és melyik a rollup?
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
2018-1, 2018-02 = januári, februári összegző biztonsági frissítés
2018-03 = márciusi összegző bizonsági frissítés csomag
Már jó ideje ilyen havi rollup-ban jönnek a biztonsági frissítések
--
trey @ gépház
Ahh értem, tenksz!
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
hajbazer likes this? :-)
Ha ez így folytatódik, akkor neki lesz igaza.
Lesz? Midigis neki volt igaza :-)
Sok igazság volt abban, amiket mondott, de a "mindig" az túlzás.
Még túlzás, aztán majd kiderül... :)
É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? :)
Úgy értem, hogy mérni kell, és ha lassabb, akkor elvetni a változtatást. Így nem lehet rosszabb.
Elsőre nem fog. Meg kell először tanulni. Épp ez a lényeg.
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.
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 miattfejfá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?
Sok fadarabot belekalapálsz a talajba, hátha megfogja egy időre.
Ez a valóságban meglepően jól működik egyébként. :)
ha lúd, legyen kövér!
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?
Ha jól tudom, nem tudják detektálni, így bizonyítani sem. Innentől kezdve lehet, hogy volt már adatlopás ezzel a módszerrel, lehet, hogy nem.
Biztonsági szabályzat első pont: aminek csak a lehetősége is valós, azt úgy kell kezelni, hogy van!
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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.
É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. :)
Én már rég elvesztettem a fonalat, gyakorlatilag sodródom az árral. :)
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
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?