Názory k článku Nový vývoj kolem Spectre a Meltdown a naštvaný Linus Torvalds
-
drobec (neregistrovaný)
Na wikipedii k tejto téme sú určité informácie, takže záleží od špecifikácie konkrétneho zariadenia:
"ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected. The ARM Cortex-A75 core is affected directly by both Meltdown and Spectre vulnerabilities, and Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72 and Cortex-A73 cores are affected only by the Spectre vulnerability.This contradicts some early statements made about the Meltdown vulnerability as being Intel-only.
A large portion of the current mid-range Android handsets use the Cortex-A53 or Cortex-A55 in an octa-core arrangement and are not affected by either the Meltdown or Spectre vulnerability as they don't do out-of-order execution. This includes devices with the Qualcomm Snapdragon 630, Snapdragon 626, Snapdragon 625, and all Snapdragon 4xx processors based on A53 or A55 cores. Also, all Raspberry Pi computers are not vulnerable to either Meltdown or Spectre."
-
Co se stalo, stalo se, ale clovek by se mel z chyb predevsim poucit. Soucasny vyvoj jednoznacne ukazuje jaka je spravna strategie pro budoucnost. Hardware (nejenom CPU) by mel byt otevreny a snadno licencovatelny, minimalne zpusobem RISC-V. Jestli se to nestane, tak se podobny problem bude opakovat nekde jinde, nekde jinak, ale potencialne s podobne katastrofickymi dusledky.
-
Hmm a jak to pomůže?
Problém nevznikl tím, že by ho někdo tajil. Problém vznikl tím, že to doposud nikoho nenapadlo. Co my víme o problémech RISCových platforem? Nic, to neznamená, že tam nejsou. Celý problém je mnohem obecnější, nejde o klasickou chybu, spíš o rys a asi nejvýraznější na celé věci je to, kolik lidí zůstalo stát s hubou otevřenou dokořán v důsledku poznání o jak velký průšvih jde. Nikoho z nich to nenapadlo.
-
Problém vznikl tím, že to doposud nikoho nenapadlo.
Tak s tím si tedy dovolím zásadně nesouhlasit. Ne, že by snad někdo dopředu znal tuhle konkrétní chybu, ale třídy problémů podobného typu jsou známy docela docela dlouho a obecný způsob ochrany taky.
To mi v podstatě dovoluje použít argument, který jsem psal už mnokrát. Za desítky let se v OS podařilo vybudovat poměrně slušnou a bezpečnou platformu pro běh programů, jejich vzájemné oddělení (na mnoha úrovních), vyřešit práva k datům apod. Všechno máme, v podstatě dnes můžeme mít každý program ve svém vlastním izolovaném prostředí. Řeší se, jak mají být podepsané balíčky a dokonce i věci jako reproducible builds.
Do toho vlezly "prohlížeče" internetu (dneska by se spíše slušelo psát: univerzální spouštěče), které ochotně spustí libovolný kód, který jim z libovolného zdroje přijde po protokolu. Tím se desítky let práce na bezpečnosti OS v podstatě zahodí a místo toho se řeší, jak web v jednom tabu oddělit od webu ve druhém tabu (tj v jednom procesu, max. mezi dvěma vlákny). A ještě jim dát přímý přístup k HW... S takovou se na nějaké podpisy balíčků můžeme fakt... víte co.
Jako já si klidně dovedu představit, že po každé takové chybě se projedou všechny balíčky v repositáři a případně se zrekompilují tak, aby tato chyba nebyla zneužitelná. Tím se dá výrobci HW čas, aby tu chybu vyřešil. Ostatně takto se to dělalo i v minulosti, hw bugy některých cpu se obcházely v kompilátoru a dané vadné instrukce se prostě nepoužívaly.
Ne, dneska máme stav, když máme sice super bezpečný os, ale stejně si ochotně spouštíme náhodné programy z náhodných zdrojů v "prohlížeči".
-
PetrM (neregistrovaný)
Blbost.
Představ si, že máš komplet otevřený zdrojáky ve Verilogu od jádra. Jak ti to pomůže předejít chybě, pokud
- je chyba v syntezátoru a něco ti z toho v rámci optimalizace vypadne blbě?
- je tam BSD licence, výrobce čipů si to forkne a nějaký expert něco ručně "optimalizuje"?
- chyba se projeví až ve spojení s konkrétní chybou SW, třeba nesmyslnou sekvencí instrukcí / nepoužívaným opcode...Tohle obecně pomůže na backdoor (nějaká cesta ven) a podobně, ne na podobný věci.
-
Důležité je hlavně nebýt závislí na jedné HW platformě. U Linuxu človĕku může být jedno, jestli používá x86/amd64, ARM nebo POWER, protože OS i aplikace (alespoň u většiny svobodného SW) jsou identické. To je dosud nedoceněná výhoda, jakou Windows ani Mac nenabízejí. Takže by to chtělo víc takových Talosů a silnější stroje s ARM. Když se pak stane něco podobného a uživatel z toho má obavy, může si koupit CPU s jinou architekturou, sice bude muset reinstalovat distro ale jinak mu všechno bude dál normálně fungovat.
-
Právě proto by se moc hodilo silnější ARM. Nejde samozřejmě o ARM jako takové, ale o to, že to je jedna z architektur, kde se Linux používá komerčně, spolu s Intel/AMD, POWER a snad ještě MIPS, a je na ní tedy podrobně testovaný a laděný. Architektury jako SPARC apod. už přece jenom nemají tak aktivní podporu (nemluvě o výkonu...), kdežto RISCV a OpenRISC ji ještě nemají.
-
Mozna jste jeste nikdy neslysel o "security through obscurity", coz by slo u HW vyrobcu parafrazovat jako "performance through obscurity". U vyrobcu CPU se tyto dve fraze dokonale prolinaji. V inzenyrske praxi se uz vice jak stoleti vi, jak je takovy model vyvoje chybny. Udivuje mne, ze zrovna vy nechapete podstatu spojenou s konstrukci HW.
ad fork) to je na volbe uzivatele, zda si koupi genuine nebo tuned
ad projev chyby) uz jste nekdy slysel o metodach formalni verifikace? Zrovna u Intelu byste v tehle oblasti nasel ceskou stopu. Jenze dodnes neni moznost sjet spravnost SW+HW vrstvy (na x86), protoze nemate otevreny HW.
-
. . (neregistrovaný)
také bych rád otevřený HW a průhlednější CPU, nedomnívám se, že v tomhle případě by se něco změnilo. Jedná se o chybu designu a postiženi do určité míry jsou všichni napříč spektrem spectrem. Sice všichni slavnostně tvrdí, že nemají takový průser jak intel, ale stejně tak všichni ví, že to je začátek a všichni mohou mít svůj meltdown, je to jen otázka času pokud to rychle nezaříznou záplatou.
Složitost x86 je podle mě naše zkáza, risc-v dělá krásné věci, arm vypadá opět velice dobře, dole zmíněný talos jsou moc pěkné architektury, ale majorita je uzavřena ve svých historických instrukcích.
-
Zmenilo by se hodne. Inzenyri by sve vykonnostni obezlicky neschovavali za oponou a bylo by mozne verifikovat prave ten design. Kvalitni verifikace je samozrejme spojena s otazkou dostupneho vykonu, ale podobne designove zavady by stezi vydrzely desetileti jako u techto aktualnich chyb. Na tyhle chyby se ostatne prislo jen diky tomu, ze jedna z mnoha korporaci prestala verit HW a "podivala" se mu na zoubek.
-
. . (neregistrovaný)
u ARM je design otevřenější a přístup k němu má velká spousta lidí a organizací, pomohlo to? Chybou je částečně postižený také.
Souhlasím, když se někdo dívá, má to pozitivní vliv na výsledek, Intel by si pozornost zasloužil. Není to první velký zářez Googlu do Intelu. Museli do toho vrazit obrovské množství prostředků a jde jasně vidět, že uzavřený kód se sice dá nezávisle kontrolovat, ale ty bariéry jsou obrovské.
-
Mně se to nelíbí, ale myslím tím mediální humbuk, včetně Rootu. Místo vysvětlení o co jde jen shrnutí mediálního odpadu z celého světa a nic z toho.
Já si vůbec nejsem jist, jestli je chyba u výrobců procesorů. Co když tím, kdo má máslo na hlavě je Linus a obecně vývojáři operačních systému? Spekulativní exekuce je rys CPU, nikoliv chyba! Že si vývojáři nevšimli, že existuje možnost side kanálu? Ať to koukají napravit! Že je Linux blbě navržený z hlediska organizace kernel vs userspace? Ví se to už dlouho, nekonečné diskuze na téma, proč se ani ve třetím tisíciletí neprosadili mikrokernelové OS. Tam kde je kernel plně oddělen od procesu, tam se nechytá aní Spectre ani Meltdown.
Dejme tomu, že Meltdown je problém, který by nakonec Intel mohl fixnout na své straně. To jak se vývojáři snaží co nejrychleji opatchovat Spectre se mi vůbec nelíbí. Tvrdím, že tenhle bug se týká jen omezeného množství programů, tam kde existuje přímá komunikace mezi procesy na úrovni sdílené paměti. Že lze javascriptem přečíst obsah celého procesu, ve kterém běží? No od čeho je sandboxing že? Že v novinách psali, že je přes Spectre možné utéct ze sandboxu? Nevěřte všemu, je to odpad. Nejde!
Spectre není bug, je to rys procesoru. Je to asi tak jako že měřením odběru proudu lze odhadnout, co počítač dělá. Jo, když to je zařízení typu Bitcoin Trezor, tak je to průser, protože lze odvodit privátní klíč nebo seed. Tam se kód musí psát speciálně, aby každá operace brala stejné množství proudu. Ale domnívám se, že 99% všech uživatelů PC tímto útokem postiženo není. Tam kde jde o kritické funkce, tam si to vývojáři fixnou. Globální patchování bude působit medvědí službu.
Až humbuk utichne, vyjdou úpravy jader a patche takové, které se nijak na výkonu neprojeví. Určitě se objeví snahy jak navrhnout OS jinak, tak aby byl odolný proti případným side kanálům způsobených spekulativní exekucí. Zároveň bude stejně rychlý jako jeho předchůdce. Vývojáři se to naučí psát dobře. Kód náchylný ke Spectre útoku se zařadí po boku jiných chyby jako třeba buffer overrun.
Spekulativní exekuce tu zůstane i nadále v nezměněné (v případě Intelu mírně pozměněné) verzi.
-
PetrM (neregistrovaný)
Linux nenaprogramoval Linus, ale pěkně dlouhá řada lidí a firem. Linux totiž funguje tak, že libovolnou jeho část můžeš použít ve svým produktu výměnou za zveřejnění úprav. Schválně, zkus si na zdrojáky jádra poštvat git blame, jestli je všude Linus. A grepni si výsledky na @intel.com, jestli tam není i někdo s informacema z první ruky.
A v praxi jsem se už hodněkrát setkal s tím, že v dokumentaci bylo něco úplně jinýho, než co ten křemík fyzicky dělal. On totiž někdo jiný navrhuje logiku obvodu, někdo jiný z toho kreslí masky pro křemík, někdo jiný to dokumentuje, další chystá testy a někdo úplně jiný to testuje. Stačí nějakou "blbinu" špatně pochopit nebo špatně vyhodnotit výsledek testu... Třeba u Atmelu mě to už stálo pěkných pár měsíců života (a díky tomu jsou Atmelí brouci na blacklistu, s nima bych si nevydělal ani na slanou vodu).
-
MarSik (neregistrovaný)
To je samozřejmě pravda. Ale Intel je velká firma a ne všichni se zabývají kernelem na úrovni MMU, TLB a cache. Takže je otázka, kdo přesně psal tu nízkoúrovňovou část a jestli nezapomněl na nějaký malý detail zmíněný v datasheetu. Vzhledem k tomu, že ten detail by nejspíše ovlivnil celkovou architekturu jádra to může být klidně důsledek dávného rozhodnutí udělaného samotným Linusem (mapování fyzické paměti do adresového prostoru kernelu a tím potažmo každého uživatelského procesu).
Z mé zkušenosti je běžné zapomenout na nějakou maličkost i u třeba Cortex M0+ implementací. A to je řádově (hodně řádů) jednodušší procesor / mikrokontroler. I tak má třeba MKE04P24M48SF0RM více jak 600 stran. Tiva C (Cortex-M4) už jich má 1400. Intel i7 bude určitě složitější..
Takže Ondřej má pravdu v tom, že to celé může být považováno za vlastnost a starost programátorů OS. Jenže na druhou stranu se architektura OS na této úrovni dost těžko mění ze dne na den.. takže nemuselo být už možné to elegantně obejít. Obzvláště, když to doteď nikoho nenapadlo a Linux je dnes pekelně složitý systém.
-
Martin DrábStříbrný podporovatel
> Takže Ondřej má pravdu v tom, že to celé
> může být považováno za vlastnostV případě Spectre bych i souhlasil (nepřímo čtu paměť, na jejíž čtení mám dle procesoru právo). U Meltdownu je ale problém v tom, že se dostanu ke stránkám, které mají nastavený bit U/S tak, aby je číst z uživatelského režimu nešlo. Pak takový bit ale celkem postrádá smysl. Myslím, že v manuálech jsem nikde neviděl deklarovanou nutnost vymazat TLB při návratu do uživatelského režimu.
Stejně by mě zajímalo, jak se tím Meltdownem dá dumpnout celá fyzická paměť, která je namapovaná ve virtuální. Protože přecejen ne všechna je odkazována v TLB a ne všechnu dokážu do TLB z uživatelského režimu "dostat".
-
MarSik (neregistrovaný)
Jak chápu Meltdown tak to je prostě spekulativní přístup do pole s pomocí neznámého indexu, který skončí v cache a Flush + Reload dává možnost zjistit, která položka pole v cache skončila, čímž zpřístupní tu neznámou hodnotu. Takže se nedostanete ke stránkám, ale k jednotlivým bytům / wordům. Větší bloky asi už nejsou reálné, kvůli velikost toho pole pro cache. Ale i tohle asi stačí s vhodným cyklem (Meltdown paper mluví o rychlosti získávání data řádově ve stovkách KB/s)
Kernel má namapovanou kompletně celou fyzickou RAM:
For a 64 bit Linux the kernel logical range lays from 0xFFFF880000000000 to 0xFFFFC7FFFFFFFFFF
where you have a direct mapping of all physical memory. Moreover, 512MB of physical memory starting at
0x0 are also mapped to the logical range 0xFFFFFFFF80000000--0xFFFFFFFF9FFFFFFF (kernel text
mapping). The memory mapping for the 64 bit kernel is described in details in the kernel documentation
under Documentation/x86/x86_64_mm.txt. -
Martin DrábStříbrný podporovatel
> Jak chápu Meltdown tak to je prostě
> spekulativní přístup do pole s pomocí
> neznámého indexu, který skončí v cacheNe, jedná se o spekulativní přístup na adresu, jejíž stránka je chráněná bitem U/S před čtením z uživatelského režimu. Pole tam pravděpodobně vidíte proto, že mnohé exploity jej tam používají pro zmatení branch predictoru.
Ano, v Meltdown whitepaperu píší, že Linuxy mapují celou RAM. Moje otázka byla, jak to mapování postupně dostat do TLB, protože jinak se ten spekulativní přístup nekoná (alespoň to mám vyzkoušené na Spectre, na Meltdown ještě ne). Protože bez TLB ten přístup bude trvat o hodně, hodně déle (je třeba provést přístupy do čtyř úrovní stránkovacích tabulek).
-
MarSik (neregistrovaný)
To pole (probe_array) se nepoužívá pro zmatení branch prediktoru, ale pro zjištění hodnoty na té adrese. Protože přímo z cache tu hodnotu nevyčtete. Dá se to ale nepřímo pomocí zjištění, která stránka skončila v cache po provedení probe_array[4096 * (*adresa)]. Koukněte na Listing 1 (a 2 pro ASM verzi) v tom paperu. Figure 4 potom ukazuje, že prostá iterace přes probe_array (kam máte přístup) stačí ke zjištění neznámé hodnoty, protože ta jedna použitá stránka z cache je rozpoznatelná podle rychlosti přístupu k ní.
Ty adresy pro mapování paměti nemám z Meltdown paperu, ale z prezentace pro debugging Linuxového kernelu. Samotná dokumentace kernelu říká:
4 level TLB:
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memoryTakže bych řekl, že to už namapováno je a MMU to bez otázek přeloží. Urychlení může spočívat čistě v tom, že tu paměť přečtete sekvenčně. Meltdown paper tvrdí, že rychlost čtení je méně než jeden MBps. To není zrovna závratná rychlost.
-
Martin DrábStříbrný podporovatel
Ano, s těmi poli jsem to zval za špatný konec. Co se týče probe_array, viděl bych jej spíš jako součást Flush&Reload útoku. Meltdown zde přidává čtení z té nepřístupné adresy (ve vašem příspěvku *adresa). Kdyby při spekulativním vykonávání instrukcí docházelo i ke kontrolue U/S bitu, tak není co řešit. Proto se nejedná o vlastnost.
> fyzická paměť
Pořád se mi nezdá, že by se tohle mapování přímo vešlo do TLB, (cache) které bude mít místo jen na cca pár stovek překladů. Že ve stránkovací tabulce bude nějaké takovéto přímé mapování, s tím nemám problém.
> Meltdown paper tvrdí, že rychlost čtení je
> méně než jeden MBps. To není zrovna
> závratná rychlost.To může ukazovat na množství operací, které je třeba provést, aby byla určitá jednotka paměti přečtena s dostatečnou spolehlivostí (obsluha výjimek, měření časování atd.).
-
MarSik (neregistrovaný)
Ano Flush & Reload je součástí Meltdown.
Při spekulativním vykonávání se příznaky nekontrolují a je to podle všeho známá vlastnost. On totiž kód může obsahovat něco jako if (root) { *(0x0) = 1 }. Spekulativně vykonaná then sekce pro non-root uživatele by musela umožnit normální provedení else větve, i když by selhala. x86 je už tak dost složitá, tohle by ještě přidalo... ale asi to v budoucnu nějak tak stejně dopadne.
Ono se to přece do TLB naráz vejít nemusí. Čte se to byte po bytu. Prostě to bude jen pomalejší. TLB si MMU spravuje sama, jestli si to pamatuju správně, tak není problém s tím, že se musí občas mapování zahodit a vložit nové.
-
Martin DrábStříbrný podporovatel
> if (root) { *(0x0) = 1 }.
Vzhledem k tomu, že do Ring 0 se dnešní OS (už velmi dlouho) dostávají skrz instrukce syscall/sysenter, popř. softwarovým přerušením, podle mě by opravdu nevadilo, kdyby si procesor někde pamatoval příznak, v jakém režimu běží, a to takovým způsobem, že by jej bylo možné použít i při spekulativním vykonávání instrukcí (jelikož jej není třeba často aktualizovat).
> TLB
Ano, spravuje jej zejména MMU (a trochu OS, když mění stránkovací tabulky). Můj point byl ten, že kódy, které jsem viděl, obvykle předtím, než provedou Meltdown, se příslušné paměti dotknou (např. vhodným systémovým voláním), než "spustí maškarádu". Takže mají v podstatě jistotu, že potřebný překlad v TLB bude. Ale tímhle způsobem se nedá dostat k celé namapované fyzické paměti (nějak deterministicky).
Ale možná, že při (nespekulativním) přístupu na kernelovou adresu procesor TLB mění, kdežto při spekulativním vykonávání přístupu na adresu, na kterou oprávnění má (můj test), se nic do TLB nepřidává.
-
lopata (neregistrovaný)
Prosím nešiř tady bludy a nepiš o věcech, kterým nerozumíš. Spectre lze využít k přečtení dat jiných procesů a tedy i k úniku ze sandboxu. Už jsem ti jednou psal jak: https://www.root.cz/zpravicky/patche-kernelu-a-gcc-opravuji-spectre-a-meltdown/954299/. Potvrzuje to i spectre paper: https://spectreattack.com/spectre.pdf
More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation
Prosím nastuduj si to předtím, než se k nečemu začneš vyjadřovat.
-
. . (neregistrovaný)
tahle otázka se řeší/řešila, viděl jsem kdysi i nějaké poznámky od Intelu v datasheetu, spekulativně se provede cokoliv, ale výsledek se použiji až po kontrole. Trik, že se k výsledku dá dopracovat vedlejšími kanály je pro mě překvapením, nejsem v tom sám.
Chyby přiznalo i IBM u Poweru, zatím pouze intel má dvojchybu a k výsledku se dá snadno dopracovat, je ale asi otázka času dokud se podobná chyba nenajde i jinde
-
Laďa Kalina (neregistrovaný)
Vrtají mi hlavou dvě věci. První, jak je možné, že Applu se povedlo Meltdown opravit údajně bez měřitelného dopadu na výkon, jak v macOS tak v iOS, zatímco ten samý procesor s Linuxem přijde o desítky procent výkonu. Buď lžou a nemají to opravené (to by si ale snad nedovolili, provalilo by se to), nebo ten linuxový patch je špatný, nebo celá architektura Linuxu je špatná takže to nejde dobře opravit bez přepsání celého vesmíru (na což zatím nebyl čas), zatímco v macOSu to šlo opravit jednoduše. Anebo měl macOS ten výkonový hendikep už před opravou, takže Linux jen přišel o výhodu/optimalizaci, kterou macOS nikdy neměl (ale to se mi nechce věřit, o takové nevýhodě macOSu by se dávno všude psalo).
Druhá věc co mi vrtá hlavou, proč ve všech titulcích se mluví o průseru intelu, když stejné dvě chybi mají prakticky všichni výrobci a na všech architekturách (např. Apple má obě chyby i ve svých vlastních armových procesorech Apple Ax které jsou v iPhonech, je to i v armových Snapdragonech od Qualcomu, v Powerech od IBM... jediný koho se to _údajně_ netýká je AMD.
No a poslední drobnost: fix v gcc? Co se může opravit v gcc? Že to nedovolí přeložit kód který by tyto zranitelnosti chtěl zneužít? -
lopata (neregistrovaný)
Zatím jsem neviděl žádné testy na Macu, ale obecně na současném hardware nejde udělat oddělení adresového prostoru kernelu a aplikace bez dopadu na výkon.
Intel má problém s Meltdown útokem, který se podle všeho netýká AMD. Na AMD zůstane paměť kernelu namapovaná v paměti aplikace bez dopadu na výkon, AMD se nezpomalí.
Spectre útoku (který se týká Intelu i AMD), může překladač zabránit tak, že nebude generovat potencionálně zneužitelné sekvence instrukcí. Tohle je teprve v začátcích, obecně existuje mnoho možností, jak provést Spectre útok a je otázka, jestli bude 100% ochrana takovým způsobem realizovatelná. Samozřejmě i tohle může mít dopady na výkon.
-
PL (neregistrovaný)
Pokud jsem to pochopil, tak vlastni gadget neni problem, pokud neexistuje zpusob, jak na nej (spekulativne) skocit. Takze staci nemit v jadre zadnou (spustitelnou) instrukci, u ktere je mozne oblbnout prediktor (JMP na adresu z pameti).
Retpolina tohle resi tim, ze se jadro pouzije prioritne predikci navratovych adres a tam je umele vlozena slepa vetev. -
Laďa Kalina (neregistrovaný)
To jsem vydedukoval z oficiálního prohlášení, že Meltdown patch je v iOS 11.2 (release 13. prosince) a pokud je mi známo, iOS neběží na ničem jiném než v iPhonech, iPadech a iPodech, a ve všech těchto krabičkách jsou vlastní applové procesory. Kdyby v nich ta chyba nebyla, nebyl by důvod patchovat iOS. Poslední iDevice se 3rd-party procesorem byl iPhone 3GS v roce 2009 (Samsung S5L8922), počínaje iPhonem 4 v roce 2010 mají vlastní procesory. iOS 11 je výhradně 64-bitový, takže nejde nacpat do ničeho staršího než iPhone 5S (procesor Apple A7).
-
Fanous (neregistrovaný)
So, yes, we the OpenBSD developers are not totally asleep and a handful of
us are working out how to deal with Intel's fuck-up aka the Meltdown
attack. While we have the advantage of less complexity in this area (e.g.,
no 32bit-on-64bit compat), there's still a pile of details to work through
about what has to be *always* in the page tables vs what can/should/must be
hidden.Do KARL or other features of OpenBSD mitigate this? Not particularly. If
you're running code from multiple trust domains then yeah, you're largely
at risk.We have received *no* non-public information. I've seen posts elsewhere by
other *BSD people implying that they receive little or no prior warning, so
I have no reason to believe this was specific to OpenBSD and/or our
philosophy. Personally, I do find it....amusing? that public announcements
were moved up after the issue was deduced from development discussions and
commits to a different open source OS project. Aren't we all glad that
this was under embargo and strongly believe in the future value of
embargoes? -
Radovan (neregistrovaný)
Apple měl na opravu půl roku a tvrdí že zpomalení je do 2.5%.
Intel na ní půl roku sral a teď tvrdí že jeho procesory jsou nejbezpečnější na světě.
Já tvrdím že obě korporace lžou.Když srovnáváš Apple s Linuxem, kolik serverů běží na OS X? V desktopovém Linuxu se ten propad téměř neprojevil, snad kromě zpomalení diskových operací, holt se nám budou déle načítat hry :-D
-
. . (neregistrovaný)
na LInuxu opravu vyřešili rychle a efektně, mažou celou cache, osobně nečekám, že to je konečné řešení, ale poskytuje efektní opravu ihned. Pravděpodobně se časem najde obrana, která nebude mít tak razantní dopad na výkon, počkejme.
Ono to velice úzce souvisí s architekturou jádra OS, proto se tak mění dopady podle platformy. Krom toho zatím kromě Linuxu není možné ani říct, co vlastně ty ostatní platformy opravily a co ne.
-
R223 (neregistrovaný)
Co jsem koukal do zrojáků, oprava v kernelu je JEN invalidování cache. Nic víc. Pak se tomu dopadu nelze divit, je to pěkná prasárna. Možná, žew jiné OS mají jiné rozložení kernel-user paměti, a opravit šli snáze, nebo na to měli víc lidí. Oprava v Linuxu mi přijde spíš jako rychlý hotfix.
-
lopata (neregistrovaný)
To by měl zajímalo, kam do zdrojáků jsi koukal? Invalidování TLB cache řeší PCID, takže se invaliduje jen to, co je nutné. Byl to tento patch: http://lkml.iu.edu/hypermail/linux/kernel/1709.0/01229.html
Enable PCID optimized TLB flushing on newer Intel CPUs: PCID is a hardware feature that attaches an address space tag to TLB entries and thus allows to skip TLB flushing in many cases, even if we switch mm's.
-
Martin DrábStříbrný podporovatel
> Zdrojovy kod ani navrhy reseni nebyvaji 100% hned
> napoprve. Vadi mi ovsem, ze se chyby zverejnily pred
> vydanim zaplat, a ze intel hraje mrtveho brouka.Nehrál při tom zveřejnění roli fakt, že si asi dost lidí všimlo "podezřelých" úprav v linux kernelu, takže se už ty informace pod pokličkou nedaly dost dobře udržet?
-
pepík (neregistrovaný)
Všichni, kdo o chybách věděli, byli pod NDA.
Tím, že v kernelu linuxu se fixy objevily ještě před dohodnutým termínem je problém.
Zároveň nebyli všichni pod stejným NDA informováni o problémech ve stejný čas. Intel má má hodně smradlavýho másla na hlavě.
Detailněji nemůžu - NDA.
-
"Jedna věc je jasná: velmi krátce předtím, než byly ony bezpečnostní chyby odhaleny světu, prodal šéf Intelu významnou část svých akcií"
Pokud by to bylo jasny, tak by bylo i jasny, ze sef Intelu ztravi spoustu let ve vezeni. Ovsem ono to uplne jasny neni. Ten prodej byl totiz automatickej a planovanej hodne dopredu, coz by ho melo osvobodit od "Insider trading" zaloby. Intel ovsem o chybe vedel od cervna, tak uvidime, jak to dopadne...
-
V USA berou zneužití insider informací při obchodech s akciemi opravdu hodně vážně, zcela reálně za to padají tresty přes 10 let (a to opravdu reálně, ne pouze teoreticky).
Myslím si proto, že dotyčný se buď zachoval jako naprostý hlupák a prakticky s jistotou si to velmi slušně odskáče anebo šlo opravdu o náhodnou shodu, kdy to bylo naplánováno déle, což bude schopen doložit. -
Nebo je moznost C, ze to bylo naplanovano tak, aby to proslo bez postihu:
"But it’s also true that the share sale was preplanned in accordance with the 10b5-1(c) rule that allows management to sell a portion of their holdings according to a predetermined schedule without attracting insider trading charges. An SEC filing reveals that this is what happened in this case."
https://www.zacks.com/stock/news/288002/intel-dips-on-chip-flaw-krzanich-accused-of-insider-trading -
To je jednoduché - odděluje ten Grsec adresní prostor jádra a aplikací (tj. to, co dělá KPTI)? Nejspíš ne.. Takže potřebuješ jádro s KPTI (nemusí to být ale zrovna 4.14 - je to backportované i do jiných).
Jinak on ten Grsecurity není kdoví jaký zázrak - je důvod, proč ty patche nebyly přijaty do mainstream jádra ;)
-
drobec (neregistrovaný)
Pravdu máš. Podľa toho čo som našiel na twitteri grsecurity, tak GRSEC v poslednej verzii 4.9.24 pred ukončením bezplatnej dostupnosti pre Archlinux, neochráni pred Meltdown. Je čas na upgrade.
AD Grsecutiry) nepoznám všetky dôvody, prečo Grsecurity neprijali do upstream kernelu, ale mne s GRSEC kernelom fungovalo všetko, čo som potreboval na prácu, tak som ho používal a používam doteraz. Myslel som, že jeho používanie budem musieť ukončiť, keď bude vydaná verzia systemd, ktorá už na mojom jadre 4.9.24 nepobeží a bude vyžadovať novšiu verziu, ale Meltdown je dobrý dôvod na uppgrade kernelu v tomto čase.
-
No obecně je ten kód dost nekvalitní (nesplňuje standardy kernelu) a svými "fixy" také občas bugy zavádí :D
Dá se toho docela dost počíst ve spojení s tou Grsecurity kauzou, kdy přestali zveřeňovat kód odvozený z GPL2 kernelu a smluvně vyhrožují neprodloužení kontraktu tomu, kdo by kód zveřejnil..
Jinak ale AFAIK existuje fork, který někdo udržuje, takže pokud ty patche chceš, zkus pohledat.
-
BobTheBuilderStříbrný podporovatelNe, naopak, odinstalujte antivirus a pak udělejte update.
Podmínkou instalace patche ze začátku ledna na Windows je, že 3rd party antivirus je s opravou kompatibilní. Pozná se to podle toho, že do:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat
nastaví DWORD hodnotu cadca5fe-87d3-4b96-b7fb-a231484277cc=0
S nekompatibilním antivirem (když tam tu hodnotu vrazíte ručně) si koledujete o BSOD. -
pushkin (neregistrovaný)
Dokážete někdo odhadnout dopad Spectre/Meltdown na výpočty metodou konečných prvků? Protože jestli to bude podobné jako s databázemi (ty matice taky nejsou vůbec malé) tak budeme mít z výpočetních serverů s Xeony akorát neskutečně předražené kalkulačky s hromadou zbytečné paměti...
-
lopata (neregistrovaný)
Oprava meltdown zpomaluje jenom syscally, takže na výpočty by to mít vliv nemělo. Na spectre se aktuálně dá aplikovat retpoline (https://support.google.com/faqs/answer/7625886), což má efekt na volání virtuálních metod, způsobí to branch misprediction při každém volání virtuální metody. Dopady záleží na konktétním software podle toho, jak moc volá virtuální metody. Retpoline řeší pouze branch target injection útok, neřeší bounds check bypass útok, proti tomu zatím spolehlivá ochrana není (kromě úplného vypnutí branch prediction, což by mělo velké dopady na výkon).
-
pushkin (neregistrovaný)
Bohužel, škodlivý kód by se tam dostat mohl - počínaje neopatrností/hloupostí uživatelů, kteří server sdílejí, konče tím, že servery jsou v síti s jinými stroji s Windows a veřejnou IP adresou (mne nekamenujte, já to nevymyslel :-/ ). Tzn. záplatovat bude nezbytné a výkonnostní dopad může udělat z Xeonů s 19k body v PassMarku desktop s 10k body a zanedbatelným výkonem na jeden thread. Což je PEKLO, vzhledem k tomu, že např. ANSYS síťuje jedním jediným jádrem (threadem) :-/
ČLÁNKY DO MAILU