Intel CPU design flaw |Meltdown, Spectre a ine|

[Dithius]

taky si myslím že to bude jen nic extra

[sirThomas]

No koukal jsem na výsledky. Toto není zas tal velký problém ve hrách atd. Ale bojím se jak se to dotkne výkonu v databázích a při mé práci. Někde jsem viděl že pokles u Enterprise systémů byl až v řádu 60%. Což by mě nasralo.. To by můj starej PC(6let) byl rychlejší než 9 měsíců nový PC!

[Eddward]

Z computerbase.de

The widely used PostgreSQL database is running at around 7 percent slower with a PTI benchmark . Linus Torvalds described this performance loss in an answer as " in line with expectations " but of course highly dependent on the actual workload. Meanwhile, there are other PhiTono PTI benchmarks that show dramatic 2-factor and greater in nSI file system benchmarks on NVMe SSDs, significant differences in the lower double-digit percentages of PostgreSQL and Redis databases, and no measurable differences Encoding benchmarks like FFmpeg and x264 as well as kernel compilation.

On a second SSD in the system in the form of a Samsung 960 Pro in M.2 storage space, the CrystalDiskMark shows a difference of almost seven percent in two out of eight calculated values ​​(screenshot), with another two to four percent behind. This is consistent with the database benchmarks linked above.

To what extent this is solely due to the patch, remains open, because Windows changes with new versions and other things on the operating system, which can have an impact. As a rule, this is less big.

However, two-digit performance losses could not be proven in the editorial test.

NVMe disky asi budu mat nejaky meratelny hit. 2 z 8 testov ukazuju do 7%, dalsie 2 do 4%.

[killerek]

Zatím to vypada na nejvetsi dopad u virtualu a databazi. To sem po dovolene zvedavej, co mi server team rekne.

[sirThomas]

Právě ty databáze jsou problém. Podle toho jak to vidím tak velká servrová řešení jako je Oracle nebo MS SQL mají v závislosti na použití dost velkou penalizaci. Až +-50% výkonu dolů... Kdybych to věděl tak jsem nekoupoval CPU za 10K. Jsem zvědavý jak se k tomu postaví intel. Jestli vyhlásí nějakou kompenzaci..

[werygood]

No koukal jsem na výsledky. Toto není zas tal velký problém ve hrách atd. Ale bojím se jak se to dotkne výkonu v databázích a při mé práci. Někde jsem viděl že pokles u Enterprise systémů byl až v řádu 60%. Což by mě nasralo.. To by můj starej PC(6let) byl rychlejší než 9 měsíců nový PC!

Pokud máš v tom starém PC Intel, tak určitě nebyl, jde to údajně až k Sandy Bridge a možná ještě dál.

[sirThomas]

No mám Nehalem což je o generaci starší. Ale bych čekal nějakou kompenzaci. Stát se něco podobného mě tak mě moji zákaznici rozdupou.

[killerek]

sirThomas: Tak to moc potěšující není. MS SQL databazi je hodne pro vyrobu. SAP uz ani nevim na cem mají postaveny. Ještě by me zajimalo, jak to ovlivni funkcnost serveru s heartbeatem v clusteru. Zrovna iXOS server v clusteru je dost nachylny na sitovou komunikaci.

[sirThomas]

Se sítí to nemá co dělat. Jestli jsem dobře pochopil tak pomocí této chyby eskalovat přístup až do vyhrazené paměti pro jádro systému. Takže se nějak SW obchází zabezpečení paměti pro jádro. No a jak moc dobře víme tak když se softwarově emuluje funkce hardwaru tak se se to vždycky dost zpomalí. Vychází se z toho že nějaké instrukce pro procesor mají díky této úpravě (opravě) dost velkou penalizaci. To že to nejvíce postihuje databáze je jasné protože tam jedou na doraz co se týče práce s pamětí. Konkrétně pgSQL má největší penalizaci cca 23% měřilo se to na jednoduchém příkazu SELECT 1 FROM..... Takže jsem zvědavý jak moc to bude dělat skopičiny při velkém zatížení.

[killerek]

Ja sem narazil i na nejake zminky o komunikaci po siti, protože to muze ovlivnit všechny preruseni v systemu obsluhovane CPU. Zrovna clustery si po siti synchronizuji obsah na urovni systemu, db i aplikace a vzajemne si hlidaji dostupnost nodu. Něco z toho ti pujde po LAN a něco po SAN.

[Krteq]

Network část může být taky postižena, ale minimálně. ISO/OSI a TCP/IP jsou tak "futureproof" že se s nějakým oddělením kernelu od userspace moc starost nedělali Cluster ani heartbeat postiženy nebudou.

Na tenhle víkend mi náš cloud provider naplánoval update XEN Hypervisoru právě kvůli téhle chybě, tak jsem zvědav jak to dopadne po patchingu... a zrovna když mám oncall :/

[hnizdo]

https://newsroom.intel.com/news/intel-r ... -findings/

[Krteq]

https://newsroom.intel.com/news/intel-r ... -findings/

Heh, nic jiného jsem snad ani nečekal. Ale u toho posledního odstavce jsem se celkem pobavil vzhledem k tomuhle a k Management Engine

...Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.

[killerek]

jj, poslední odstavec pobavil. Pridam k tomu, ze Cisco není nadsene z jeho varky degradujich Atomu, co dalo do ASA FW boxu. U tech ještě budu muset rozjet RMA az mi dojedou soucasne velke projekty.

[Krteq]

Tak trochu víc info přímo od Googlu - ty vulnerability jsou vlastně 2 - "Meltdown" a "Spectre".

První je o tzv. "Meltdown" (Intel only), který dovoluje útočníkovy číst obsah stránek paměti v nešifrované podobě. AMD to řeší skrze SME/SEV, takže obsah paměti je vždy šifrovaný na HW úrovni a neměli by tedy potřebovat kernel/OS patch.

Druhá vulnerabilita, "Spectre", postihuje CPU všech IHVs a jde o to, že aplikace může získat komplet přístup do paměti jiné aplikace.

[Jan Olšan]

Chyba Meltdown je to, kvůli čemu se dělá ten zpomalovací patch (kPTI), a ta je zřejmě jen u Intelu. Vzhledem k tomu, že je to únik dat z kernelu, tak je to asi i závěžnější.

BTW to PRko Intelu je docela dobrá práce, dokážu si představit, jak ty formulace pečlivě sestavovali (já bych jim to nezazlýval, práce těch lidí je prost+ v tuhle chvíli dělat damage control a dělaj co můžou).

[killerek]

Doc bude asi zklamany, protože jeho vyhlizene TSX instrukce to snad i zjednodusili. Z dokumentu vyplyva, ze to Intel vedel od cervna a asi od te doby se do toho zapojili snad všichni, aby to poradne proverili.

Jinak dle dokumentu je to slusna rana pro containery jako je Docker, tam je to snad nejhorsi.

[Eddward]

Takze uz aj vieme odkedy to Intel vie.

Jann disclosed the issue to Intel in June.

Dostupny je uz update Win 10 v1709 / 16299.192
https://support.microsoft.com/en-us/hel ... -kb4056892

[del42sa]

https://mobile.twitter.com/misc0110/sta ... 7491786752

[hnizdo]

První je o tzv. "Meltdown" (Intel only), který dovoluje útočníkovy číst obsah stránek paměti v nešifrované podobě. AMD to řeší skrze SME/SEV, takže obsah paměti je vždy šifrovaný na HW úrovni a neměli by tedy potřebovat kernel/OS patch.

S sifrovanim RAM to vubec nesouvisi. Jak uz tu padlo, predmetna zranitelnost spociva v provedeni neprivilegovaneho kodu ktery se dostane do pametove oblasti kernelu jeste predtim, nez je spustena kontrola privilegii a kod je zablokovan. Pokud je neprivilegovany kod validovan chybne jako privilegovany, je mu oblast ram desifrovana (pokud je zasifrovana), at uz jakoukoliv metodou.
AMD cpu dle dosavadnich zprav touto zranitelnosti netrpi nikoliv kvuli sifrovani, ale kvuli odlisnemu zpusobu implementace postizene metody. [EDIT: a o tom se zatim vedou spory]

Co se tyce sifrovani ram u amd, AFAIK sifrovani se zapina na pozadani, v linuxu jeste neni pripraveno, a do budoucna s diskutovanou moznosti vypnuti SecureProcesoru nemusi byt vzdy k dispozici.