Vlákno názorů k článku Nový vývoj kolem Spectre a Meltdown a naštvaný Linus Torvalds od Laďa Kalina - Vrtají mi hlavou dvě věci. První, jak je...

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/optima­lizaci, 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?

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.

Přesně: patching gcc (clang, ...) to identify the array2[array1[x]] gadget and stuff it full of 199 NOPs so that the correct value for x can be brought back from DRAM before evidence is left on the cache lines.

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.

"Apple má obě chyby i ve svých vlastních armových procesorech Apple Ax které jsou v iPhonech"
Jaky zdroj jste cerpal? Kde jste tuto informaci vzal?

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).

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?

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

Já jsem to chápal tak že jde o veškeré I/O, nejenom diskové operace, ale obecně souborové operace. A když v linuxu/posixu je “soubor” prakticky všechno, tak se de fakto jedná o všechna systémová volání.

Ale stejně je zajímavé, že to má u SSD větší dopad než u HDD.

Nabude to tím, že SSD mají řádově větší IOPS?

HDD je takova brzda, ze nejake cisteni adresniho prostoru se tam da proste misto cekani ;-)

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.

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.

A to na tu opravu meli nekolik mesicu....

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.

V pripade Spectre nemusi ani vyprazdneni cache pomoct - postrani kanal muze byt napriklad tabulka prediktoru skoku, kolize na sbernici, sdileni cache mezi jadry, doba trvani volani jadra ...