Názory k článku RETBLEED: nedořešené chyby v procesorech nás budou stát až desítky procent výkonu

Jen malá oprava, E3–1260L v5 je Skylake, ne Sandy bridge.. Zajímalo by mě, zda tedy Sandybrige opravdu trpí záplatami méně...

skusim to pozriet mam i5-2500.

na Baytrail ten pokles nie je tak velky.
ale ten zase nie je nachylny na niekrte:

Vulnerabilities:
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds mitigation: Clear CPU buffers; SMT disabled
Type: meltdown mitigation: PTI
Type: mmio_stale_data status: Not affected
Type: spec_store_bypass status: Not affected
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2
mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected

Pravdu díš, opraveno, díky. Občas se člověk v těch kódových jménech zamotá. Čas od času nabudu pocitu, že bych to mohl shrnout do tabulek v nějakém článku, architektury, typy jader, generace atd. A pak si řeknu, že snadnější by bylo napsat disertační práci spojující v přelomové teorii obecnou relativitu s kvantovou mechanikou a zase mě to přejde.

By me zajimalo jaky dopad na vykon ma mitigations=off, vuci stavu kdy by v kernelu nebyla zadna zaplata ani ve zdrojaku. Jiste.. je to nejaky if(var) sem a tam.. ale presto to cloveka rozciluje, kdyz stavi embedded ostrovni system a vady cpu jsou mu.. ta tam, kam slunce nesviti.

Naštěstí je většina těch mitigací implementována přes live patching, takže těch ifů tam za běhu moc nebude, určitě ne tam, kde by to riskovalo cache miss nebo zmatení branch prediktoru.

Zase tolik bych se s tím netrápil, není to nic nového, arch/x86/kernel/cpu/bug­s.c pamatuje 90. léta, většinou se do něj jen přidává. Mají to tam pěkně tříděno pomocí maker, takže když např. stavím kernel pro nějaký embedded ARM nebo MIPS, tak se většina těch x86 větví ani nezkompiluje a zbytek to vyhází v rámci LTO, když se poštěstí. Na ARMu jsou mitigace navíc mnohem granulárnější, v configu si můžu zapnout nebo vypnout konkrétní erratum, takže když stavím něco pro jednojádrový 400MHz Cortex A7, mám jistotu, že tam nebudu mít ani jednu zbytečnou NOP instrukci navíc :-D

Pri Industry 4.0 už nie je skutočne ostrovný žiadny systém

Muzete toto marketingove tema rozvest? Nebo je to po vykradeni 5G frekvencnich pasem lobysty z velkych firem pro prumysl 12346789.006 dalsi pokus jak prodat Industry 4.0 cool cloud security solution?

I kdyz to vemu do onlinu. Jaky vliv ma retbleed na nejake zapomenute cidlo ktere jde pres svoji gw ktera sbira dejme tomu data pres nejaky cmoud? Proc bych mel strategicky dulezity system zapojovat na primo do cmoudu? Proc ty udaje nefiltrovat a do cmoudu neposilat jen vybrane?

Pokud dojde k zasazeni cmoudu tovarna musi stale jet. Jinak ten system navrhl nezodpovedny ignorant.

Hele technicky dotaz. Jesli to chapu spravne, tak jde o unik dat, ke kterym se dostane kernel ve smyslu, ze existuje zpusob jak je vyadresovat. Jinak receno jsou nekde v mape virtualni pameti, protoze vsechny postrani kanaly (napriklad BTB) ktere se vyuzivaji jdou pres MMU.
Je takto mozne precist fyzickou pamet, ktera nema mapovanou virtualni adresu?
Zajimave je to z pohledu virtualizace. Kdyz pustim exploit v kontajneru, dostanu se na chranenou pamet kernelu kontajneru, nebo existuje prima cesta na kernel hosta?

Kontejner nema svuj kernel prece, pojem host-guest je az u skutecne virtualizace.

A zda lze ziskat obsah pameti kterou spravuje hypervizor.. at zodpovi nekdo jiny.

Ano, ide to.
Ale ako vsetko v tomto vlakne spomenute, nie tak kednoducho.

Myslel jsem plnou virtualizaci. Takze quest, kontajner me ujelo.

muze prosim nekdo kdo tusi napsat jak obecne tato ci predesle muzou realne zafungovat pri pouzivani desktopu? ziskani dat ci roota vlastnikem webove stranky v prohlizeci? pres otevrenej (pouze) ssh port? resp. obecne jak vzdalene? neresim utok typu nekdo si sedne k pc s prihlasenym userem, ani utok z jineho pocitace ve stejne siti, ani pripadna skodliva aplikace v pripadnych Windows ve virtualu... dekuji :-)

Hrubě teoreticky, napadení přes prohlížeč (nějakou škodlivou stránkou je se současnými prohlížeči a jejich opatřeními nemožné, ten kód by to zabilo dříve než by načetl pár bitů).

Technicky by bylo možné pokud se útočník dostane z prohlížeče ven, nebo zaútočí jiným kanálem, např. trojan a toto využít k eskalaci svých práv (načíst si třeba paměť, kde jsou data soboru shadow nebo jiná hesla/soukromé klíče).

Napadá mne i vyčítání citlivých dat z jiných aplikací na mobilním telefonu, pokud chci někoho sledovat apod. (BTW na ARM to také funguje viz https://developer.arm.com/Arm%20Security%20Center/Spectre-BHB)

Nicméně existují i snadnější způsoby, jak eskalovat práva a toto je opravdu jeden z těch časově nejnáročnějších, na druhou stranu pokud mám jistotu, že záplaty v jádře nejsou, asi má smysl o využití této cesty uvažovat.

Větší problém to ale je pro cloud, kde je potřebná izolace a všechny tyto zranitelnosti do toho hází vidle.

Takže jaký je závěr?

Na desktopu je OK vypnout mitigace?

Pokud mám svůj cloud/server jen pro sebe, tak vypnout mitigace?

Pokud hostuji cizí aplikace, tak mě to trápí?

V securitě to většinou takto snadno říct nelze.

Lze říci, že na desktopu to snižuje riziko jen mírně a pokud na něm neděláte nic pracovního pod NDA, a svoje data nepovažujete za extrémě citlivá, tak bych to asi klidně vypnul. Jen offline zálohovat, protože ransomware je svi*a.

Pokud máte na desktopu pracovní data pod NDA, nebo tam děláte nějaký projekt/výzkum se kterým chcete prorazit, asi bych raději tu trošku výkonu obětoval a za cenu toho, že mohu tvrdit, že jsem udělal, co bylo v mých silách pro ochranu těch dat.

V cloudu must-have a co se týká serverů, tak opět podle toho, jak je kritický, z pohledu zabezpečení a jak je "zabetovnaný", spíše však ano.

To zrovna neni troska vykonu. Mam na notasu data pod NDA ale na RETBLEED z vysoka kaslu. Rizika jsou uplne nekde jinde. Extremne citliva data z principu veci nejsou nikdy zpracovavana na koncovych desktopech. Maximalne to jsou fragmenty pokud nekomu neco utece. Desktop je jen v podstate terminal klient.

V cloudu rozhodne must have neni. I pro nedulezite interni sluzby na kterych je vice internich zakazniku neni retbleed nasazene protoze nam proste pokles vykonu ted nikdo nezaplati (uz jen pro vcasne dodani bez mesicu cekani potrebujete privatni cargo letadlo) a ta data nejsou tak dulezita resp. vektory utoku kterym je treba se venovat jsou zde uplne jine.

Rozhodne si nemuze clovek dovolit aplikovat neco nekam

U zakosu mame rozdelene tridy zabezpeceni a samozrejme na dulezitejsi levely ktere treba zpracovavaji kriticky dulezita data (vetsinou je to i privatni cmoud s vlastnim zelezem) jsou zaplaty aplikovany - po otestovani a oznameni ze dojde ke snizeni vykonu. Hlavne tohle neni typicka 0day.

Tak ty patche se napoprvy uplne nepovedly...
https://lore.kernel.org/lkml/YtFPN7ctriCPVNWs@kroah.com/