Red Hat a bezpečnostní chyby Spectre a Meltdown (diskuse)

[trekker.dk]

Ten odkaz na možnosti optimalizace jim nějak nefunguje, ale podle toho prvního článku tam není popis možností optimalizace, ale popis, jak tu opravu na red hat kernelech vypnout.

[Rezza]

Funguje - Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables.

[MadCatX]

Rozumím správně, že aktualizace zatím přistály jen v Enterprise distribucích? Na serveru s CentOS 7 mám 3.10.0-693.11.6.el7.x86_64, příslušné přepínače v debugfs a microcode_ctl 2.1.22.2.el7. Je tam bohužel SNB, takže Spectre tam i dál funguje jedna báseň. Na desktopu se Skylakem a F27 je starší microcode_ctl 2.1.19.f27 a aktivní pouze PTI. Zkoušel jsem ručně nainstalovat poslední mikrokód od Intelu ale zřejmě je to ta stejná verze, jakou momentálně balíčkuje Fedora.

[n]

Ten kernel u CentOSu je uplne stejny jako ten z https://access.redhat.com/errata/RHSA-2018:0007 - vic od nich necekej. Zadny novejsi microcode_ctl nez mas pro RHEL neexistuje.

[petr_p]

Samotná instalace RPM balíku s novějším mikrokódem nestačí. Ještě je třeba jej nahrát do procesoru. A od té doby, co Intel začal odstraňovat instrukce, tak Linux odebral možnost zavádět mikrokód za běhu a místo toho je třeba přegenerovat initramfs, kam se zkopíruje mikrokód ze souborového systému a odkud se při příštím bootu zavede.

Kromě toho na Sepectre žádná univerzální oprava neexistuje (kromě úplného vypnutí spekulativního vykonávání instrukcí) a asi ani existovat nebude.

[petr_p]

A vedle toho se zdá, že Intel vůbec žádný nový mikrokód nevydal. Poslední verze je 20171117.

[MadCatX]

Ten bezpečnostní bulletin RH jednoznačně uvádí, že pro částečné ošetření Spectre útoků je nutný aktualizovaný mikrokód a novější verze microcode_ctl, která by jej měla obsahovat (https: //access.redhat.com/errata/RHSA-2018:0012). I když jsem ten balíček z CentOS 7 nacpal do F27 a přegeneroval initramfs, verze mikrokódu pro SKL je stále stejná... hm.

[snajpa]

[root@node1.pgnd.vpsfree.cz]
 /sys/kernel/debug/x86 # rpm -qa | grep microcode
microcode_ctl-1.17-25.2.el6_9.x86_64
[root@node1.pgnd.vpsfree.cz]
 /sys/kernel/debug/x86 # microcode_ctl -u
microcode_ctl: writing microcode (length: 1302528)
microcode_ctl: microcode successfuly written to /dev/cpu/microcode
[root@node1.pgnd.vpsfree.cz]
 /sys/kernel/debug/x86 # for f in `ls -1 *ena*`; do echo "$f = `cat $f`"; done
ibpb_enabled = 0
ibrs_enabled = 0
pti_enabled = 1
[root@node1.pgnd.vpsfree.cz]
 /sys/kernel/debug/x86 # echo 1 > ibrs_enabled 
-bash: echo: write error: No such device
[root@node1.pgnd.vpsfree.cz]
 /sys/kernel/debug/x86 # cat /proc/cpuinfo | grep "model name" | head -n1
model name      : Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz

Taky akorat koumam, jak to s tim updatovanym mikrokodem mysleli.

[petr_p]

Odkazované oznámení uvádí microcode_ctl-2.1-22.2.el7. V odpovídajícím commitu do zdrojového balíku se píše:

+Source3:        06-3f-02
+Source4:        06-4f-01
+Source5:        06-55-04
[...]
+* Fri Dec 15 2017 Petr Oros <poros@redhat.com> - 2.1-22.2
+- Update Intel CPU microde for 06-3f-02, 06-4f-01, and 06-55-04
+- Resolves: #1527358

Takže to vypadá, že Intel poslal opravu jen na tři procesory přímo Red Hatu, anižby se o ní podělil s veřejností.

Buďto tohle znamená enterprise podporu, nebo si Intel nevěří a raději se schová za Red Hat.

[little.owl]

Takže to vypadá, že Intel poslal opravu jen na tři procesory přímo Red Hatu, anižby se o ní podělil s veřejností. Buďto tohle znamená enterprise podporu, nebo si Intel nevěří a raději se schová za Red Hat.

Spise ho k tomu Red Hat dokopal, stejna jako Apple. S distribuci microcodu je neco shnileho, Microsoft to hodil na vyrobce zarizeni a pro plno procesoru to neni k dispozici.

[MadCatX]

Vypadá to tak, podle ID těch souborů by to měl být mikrokód pro následující řady:

• 06-3f-02, CPUID: 306F2, Xeoní Haswelly a i7 Haswell E
• 06-4f-01, CPUID: 406F1, Xeoní Broadwelly a i7 Broadwell E
• 06-55-04, CPUID: 50654, i9-7900X Skylake

Já věděl, že si mám koupit procesor za pětadvacet táců, abych měl nárok na nějaký support :) Nějaký Haswell-EP máme v kanclu ale nějak na něm ztuhlo SSHčko, takže CPUID zjistím až v pondělí...

[pc2005]

Já věděl, že si mám koupit procesor za pětadvacet táců, abych měl nárok na nějaký support

welcome to capitalism

[snajpa]

Ja jsem aktualne vcelku vystraseny, protoze Sandy Bridge-EP uz jsou EOLed podle ARKu, tak nevim, jak moc mam cekat novy ucode. Ivy Bridge-EP jeste EOLed neni; cili by to znamenalo nakup 22 second-hand procesoru. Pokud nevyjde ucode ani pro IVB, tak je to v riti, protoze to znamena nakup 15ti desek, 32 procesoru a 3.8TB DDR4 RAM. A ani to neni jiste, ze vlastne bude stacit, bo jake zranitelnosti se daji cekat za rok? Jak dlouho pak bude podporovany Haswell? No... snad Intelu prestane j*bat a uvedomi si, jakou maji zodpovednost...

[trekker.dk]

Nebo 15 desek a 15 procesorů, když se poohlédneš u konkurence

[snajpa]

No jestli to Intel zazdi, tak aktivne premyslim nad variantou z techhle serveru udelat distributed storage, nakoupit ThreadRippery a consumer desky, hromadu 12V zdroju, hromadu soucastek na DC/DC menice a poskladam to na aluprofilech a zip-ties. A k tomu pridame o rack vedle podobny build, akorat se single board computery, pro lidi, co prestanou verit shared computingu obecne. Aktualne se snazim nejako vypocitat, jak moc je to realne a jak ve velkem, ale nejako je a otazkou je asi jenom velikost takove akce.

[snajpa]

A uplne jsem prehlidnul single-socketted nabidku EPYCu, no... tak netreba se zabyvat TR, kdyz EPYC vyjde jako presne to, co aspon podle parametru potrebujem. Akorat teda doufam, ze vydaji rozumne brzo update mikrokodu.

[trekker.dk]

Jo. Nedávno jsem slyšel povídání od technického ředitele Abacusu ohledně novinek a v podstatě EPYC popisoval tak, že na co předtím byly potřeba 2 sockety, tak teď bude stačit jeden. A 2 sockety se použijou tam, kde předtím byly potřeba 4.

Trochu nepříjemný je, že co jsem zatím koukal u Supermicra, tak moc nedělají celé servery - tam kde jo, tak už taky začali s tím BS, že "kvůli složitosti montáže se to dodává jako hotový výrobek" (čti "zaplať nám marži za procesor a paměti.")

A samotnému se mi to montovat nechce, vždycky, když to pak zapnu, tak mám pocit, že by to podle všech zákonitostí elektroniky nemělo fungovat.

Akorat teda doufam, ze vydaji rozumne brzo update mikrokodu.

Tipuju, že to stihnou dřív, než začneš nakupovat

[snajpa]

Tipuju, že to stihnou dřív, než začneš nakupovat

Ja uz bych aj, kdybych mel jistotu, ze to udelaji poradne a bude vsechno OK. Desku uz mam vyhlidnutou, checkuju kompatibilitu s chassickama, co uz mame, at toho nemusime nakupovat tolik. Otazka je, jestli mam plasit a nahrazovat i Ivy Bridge. No a namontuju si to cele sam, nove masiny taky radsi, pokud neprejdeme k robotum skladanym Dellum. U Abacusu uz si nenecham montovat nic, to si radsi dorezu ruce jednou za par mesicu sam.

[trekker.dk]

Abacusu uz si nenecham montovat nic

Nikdy jsem od nich nic neměl, takže nemůžu soudit - a vzhledem k tomu, že nakupujeme celé stroje i s deskou, tak u dodavatele do toho akorát namontují procesor a připlácnou na něj chladič. Na tom není co zkazit.

to si radsi dorezu ruce jednou za par mesicu sam

O pořezání rukou mi nejde, to se mi moc nestává - spíš o to, že mám vždycky pocit, že jsem musel něco urazit nebo ohoblovat na té desce. (Nicméně kupodivu vždycky všechno najelo a fungovalo.)

[snajpa]

Na tom není co zkazit.

Fiha, to jsem si myslel taky. Pak se ukazalo, ze neni moc dobrej napad, kdyz mas ve vytizeny masine procesory, ktery nekdo drzel upocenym palcem primo za pady. Pak muzu menit RAMky jak idiot. Stacilo vycistit procesory zespodu a najednou je klid.

O pořezání rukou mi nejde, to se mi moc nestává - spíš o to, že mám vždycky pocit, že jsem musel něco urazit nebo ohoblovat na té desce. (Nicméně kupodivu vždycky všechno najelo a fungovalo.)

Ona toho vydrzi fakt hodne. Ale ty plechy nemaji sundane hrany a kdyz neco montuju po delsi dobe, vzdycky na to zapomenu davat bacha. Pak koukam, ze o co jsem se zas porezal, kdyz odchazim z DC...

[Käyttäjä 11133]

No... snad Intelu prestane j*bat a uvedomi si, jakou maji zodpovednost...

Zhruba stejnou vůči svým zákazníkům, jako máte vy vůči svým členům? :)

[trekker.dk]

Řekněme, že různé organizace mají různě velké tendence se na tu odpovědnost vys*at. A zrovna Intel má v tomhle ohledu co dohánět dlouhodobě.

[Käyttäjä 11133]

Tak když to má dlouhodobě tak asi někdo dělá tu chybu, že kupuje jejich produkty, když je to pro ně faktor.

[snajpa]

Ktere procesory jsou prosim odolne proti Spectre a proti tomu, co po Spectre prijde? Tj. proti timing attackum na kazdou prechytralejsi cast CPU? A jak to clovek z kristalove koule vyvesti 5 let predem?

[Käyttäjä 11133]

Zkus se zeptat v NASA, ale určitě to nebude nejrozšířenější varianta nejrozšířenější uzavřené architektury...

[snajpa]

No, to ma dve roviny. Jedna rovina je pravni vymahatelnost, druha je, cemu ja rikam "stavovska cest".

Nemyslim si, ze pujde plosne Intel donutit k tomu, aby se zachoval jakkoliv, jedine neprimo - pres pokuty ze strany establishmentu. vpsFree je na tom z legal stranky, rekl bych, vcelku podobne - muzeme dostat pokutu/soudni prikaz, v krajnim pripade nas muze soud rozpustit.

Podstatnejsi je podle mne drzet si "stavovskou cest". Pokud o sobe tvrdim, ze se snazim neco delat, jak nejlip umim, tak to preci nemuzu reagovat, jak Intel reaguje - jeste k tomu ponekolikate, ne poprve.

Ale neni to fer srovnani, vpsFree nic neprodava a verejne nenabizi zadnou placenou sluzbu. Clovek se musi stat clenem a potom uz je mozne rici, ze je svym dilem za chod spolku spoluodpovedny (zrovna tak, jako ma prava, s nimi jdou zodpovednosti). Tedy my nemame zakazniky. A uz vubec tam nemame tu asymetrii, ze jednou prodame fyzickou vec - a tedy nejsme ani v pozici neceho fyzickeho lifetime/lifecycle, abych mohl na nazornem prikladu ukazat, jak si myslim, ze se to *ma* delat.

To budu moct az za par let ze snah, co vyjdou ze sklepa u nas v Brne - vcelku bych se vsadil, ze budeme delat veci, ktere budou mit (a budou muset mit) podporu minimalne 15 let, spis tak 20 a vic.

[trekker.dk]

Podstatnejsi je podle mne drzet si "stavovskou cest"

To dělají lidi a to ještě ne všichni. Korporát moc ne.

[d.c.]

Korporát to přeci snadno marketingově vyrobí fiktivní postavou (personifikací vlhkého snu marketingového), řeknou třeba: to ne my, ale Mr. Server.

[Käyttäjä 11133]

Myslím si že korporát hledí na reputation damage víc, než malé firmy, nebo živnostníci...

[d.c.]

"citation needed"

[Conscript89]

No, tak nevim jak chces ocitovat, to ze si nekdo neco mysli, kdyz to navic rekl/napsal sam.

[Käyttäjä 11133]

Už to máš dávno ocitované. Mám ti to vytisknout, podepsat ručně a poslat poštou na adresu trvalého bydliště?

[d.c.]

Inu, jak pravil kdysi jistý docent Rezek: "pane kolego, můžete zkusit tu svou hypotézu nějak podepřít nebo přepracovat, nicméně se domnívám, že vaše teze je neudržitelná."

[Käyttäjä 11133]

Tak třeba už jen pokud příjmeme premisu že korporace musí být kótovaná na burze, tak ji můsí více záležet na reputsci, než soukromě držené malé společnosti, protože to má přímý vliv na její hodnotu akcií, což přímo ovlivňuje šířku rozvahy pokud vlastní nějaké své vlastní akcie; a tedy i schopnost získat kapitál prodejem akcií, nebo jejich novou emisí.

Zatímco malé společnosti mají jen jednoho reputation oriented stakeholdera - zákazníky; tak korporace mají ty stakeholdery z tohoto pohledu dva, investory - vlastníky a zákazníky.

[kralyk z abclinuxu]

Tak třeba už jen pokud příjmeme premisu že korporace musí být kótovaná na burze, tak ji můsí více záležet na reputsci, než soukromě držené malé společnosti, protože to má přímý vliv na její hodnotu akcií

V tom je právě jádro pudla - reputaci u jakých lidí. Velká korporace si potřebuje primárně udržovat reputaci u shareholderů a bohatých zákazníků (ie. typicky opět velké korporace nebo dokonce govt sféra), tj. obecně v kruzích, které, přestože se jedná o technologie a průmysl, nesestávají z oborníků. U menší firmy to bude vyrovnanější nebo spíše naopak jím půjde víc o odborníky.

Právě proto bohužel ten typ bullshit PR, jaký předvedl Intel, nejenže nebude vadit, ale nejspíše mu pomůže z bryndy, protože to, že to je bullshit, řeší víceméně jen odborná část veřejnosti.

[Bedňa]

Po rokch v dvoch veľkých nadnárodných spoločnostiach, môžem povedať, že imaginárna hodnota sa vyrába v Excelovských tabuľkách a dáta sa priohýbajú v rámci toho ako chcú akcionárov odrbať, pardón, informovať.

Proste v tých gigantoch nieje možné ani pomocou daňového úradu zistiť, že sú deň pred krachom.

[little.owl]

Ja jsem aktualne vcelku vystraseny, protoze Sandy Bridge-EP uz jsou EOLed podle ARKu, tak nevim, jak moc mam cekat novy ucode.

Sandy Bridge by mel jeste casem dostat podle ruznych zdroju update, ale ted se spise soustredi na nejvice postizene novejsi procesory, ktere stale prodavaji. Jinou veci je, ze updaty podle vseho zatim moc neresi ...

[Rezza]

No ta hlavni otazka je, co vlastne ten novy microcode dela. Jak to chapu ja, tak je to jen nove cpuinfo, diky kteremu je mozne na novejsich procesorech nedelat nektere veci a tim usetrit trosku toho ztraceneho vykonu. Ale mozna to je jen jedna cast. A mozna si jen pletu pojmy s prujmy, protoze kolem toho bylo tolik ruznych diskuzi, ze jsem z toho jelen.

[Peter]

To je skutočne výborná otázka, pretože podľa pôvodných informácií, meltdown sa pomocou mikrokódu vôbec nemal dať opraviť.

Takže asi skôr pre Spectre, tam boli informácie typu "plátať sa to bude dlho a všade možne", čiže tiež to asi nebude len vecou zásahu do mikrokódu.

Otázkou je, či mikrokód je nutnou alebo postačujúcou podmienkou opravy, alebo bude len poskytovať nejaké barličky pre kernel, aby záplata mala menej katastrofálny dopad na výkon. Lebo výrobcovia SW sa to hodlajú záplatovať každý po svojom, dokonca GCC robí zmeny, ale napriek tomu, AMD ktoré je málo postihnuté, vydalo patch mikrokódu aspoň pre Spectre v1, a ktovie, raz možno vydá aj pre v2, len pre prípad, ktorý je podľa nich iba čisto hypotetický.

Z toho, čo som čítal o úpravách v SW, aby po určitých operáciách "zametali stopy" v registroch a cache, tak to mi pripadá ako postačujúce riešenie, preto mi úloha záplaty v mikrokóde nie je celkom jasná.

[Peter]

Aha, tak na Arstechnica diskutujú o podobných úvahách:

https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/?comments=1&post=34582983

[little.owl]

Z toho, čo som čítal o úpravách v SW, aby po určitých operáciách "zametali stopy" v registroch a cache, tak to mi pripadá ako postačujúce riešenie, preto mi úloha záplaty v mikrokóde nie je celkom jasná.

Zalozit bezpecnost systemu na predpokladu, ze aplikace jsou "rozumne" napsane je cesta do (_!_).

[Rezza]

"On pre-Skylake CPUs, kernel countermeasures – and on Skylake and later, a combination of a microcode updates and kernel countermeasures known as Indirect Branch Restricted Speculation, aka IBRS – to kill Spectre Variant 2 attacks that steal data from kernels and hypervisors." pisou na https://www.theregister.co.uk/2018/01/05/spectre_flaws_explained/

[Bedňa]

To sú také náhody, zrovna sme na IRC mali debat o špekulatívných výpočtoch a čakaní na dát z RAM a čo robiť aby sa procesor neflákal. Opravou odstránia celý ten úžasný pokrok, toto kompletne degradovalo všetky procesry. Hocijaká náprava to vráti tak 15 rokov nazad a degradácia výkonu bude viac ako sa píše, určite podstatne viac.

Je to proste v pedeli a reálne neriešiteľná situácia. Teraz ma rochu hreje, keď som písal, že Intel stojí za prd a volím proti ním peňaženkou.

[trekker.dk]

Opravou odstránia celý ten úžasný pokrok, toto kompletne degradovalo všetky procesry. Hocijaká náprava to vráti tak 15 rokov nazad a degradácia výkonu bude viac ako sa píše, určite podstatne viac.

Pochybuju o tom - degradovat výkon na úroveň deset let zpátky, to by si nelajznuli, takovou opravu by (téměř) nikdo nenasadil. Vyštrachat v rozpočtu prachy na to zvětšit si datacentrum na dvojnásobek, na to jen tak někdo nemá.

[pc2005]

No já nevím, ale 2005 bylo ~3.8GHz Pentium 4 Extreme Edition, což je dneska taky +- nejvyšší rychlost. Od té doby se rychlost dohání laděním HW na nejčastější speciální případy v SW.

[Michal Kubeček]

A jader mělo to tehdejší Pentium 4 také +- stejně jako dnešní procesory stejné kategorie?

[pc2005]

Tak se současným počtem jader, by se to P4 protavilo skrz desku.

[trekker.dk]

Takže zjevně přechod zpět k P4 je degradace výkonu

[Bedňa]

Problém číslo jedna je čakanie na dáta z RAM a kým sa CPU nudí zaplní špekulatívny výpočtami cache, čo teraz nemôže. To bude čistý prieser a na serveroch si žiadny ojeb nemôžu dovoliť, inak im to hocikto dá dole.

[Bedňa]

Čím som chcel povedať, že výkon procesorov klesne tak na 30% deklarovanej hodnoty (nie o 30%) a možno menej. Ono sa to dá ľahko vypočítať podľa zaťaženia.

[trekker.dk]

To bude čistý prieser a na serveroch si žiadny ojeb nemôžu dovoliť, inak im to hocikto dá dole.

I vy naivko.

[little.owl]

Bude to nadherna prilezitost jeste vice diverzifikovat procesory navic podle mnozstvi security features, bezpecnost za priplatek, plne zabezpeceni jen v super drahe enterprise verzi.

[Bedňa]

Mno podľa mňa skôr padnú miliardové žaloby za to, keď vedome predávali deravé procesory s chybami o ktorých vedeli.

[snajpa]

Otazecka na ten Haswell a tyhle "fixy" - nemusi byt ucode loadnuty "early"? Pokud je tam fix pro Haswell-EP, tak se mi to jevi, ze jo.

[petr_p]

Intel v jedné z revizí mikrokódu vypnul na Haswellu instrukci. Pokud se zavedl až po tom, co glibc otestovala procesor na její přítomnost, tak dotyčná glibc funkce zavolala zrušenou instrukci a proces dostal SIGILL. Časné zavedení probíhá před tím, že Linux spustí init. To je celý důvod, proč na Haswellu je dobré zavádět mikrokód brzy. Není to však nutná podmínka. Mikrokód se zavede tak jako tak.

[trekker.dk]

Debian to dělá z initramfs

[petr_p]

AMD zvolilo stejnou cestu. Obranu proti Specteru vydalo jen pro procesor Epyc a podělilo se o ni jen s komerčními distributory.

[pc2005]

Zase jestli o tom intel ví od konce léta, tak mohl tu opravu už tajně zveřejnit i v listopadu ne?

[little.owl]

Google to Intelu podle vseho rekl v cervnu a ani to jim nebranilo prezentovat pak zakaznikum tohle. Zacina mi byt lito lidi, kteri si koupili neco od Intelu za poslednich pul roku, ti byli vedome podvedeni.

[kralyk z abclinuxu]

Já bych ten Intel hate zas tak nedramatizoval. Ars technica kritizuje Intel PR (pochopitelně), ale AMD PR kritizuje taky a chválí pouze ARM. Co se týče domácích strojů a workstations, IMHO i přes Meltdown budou Intel CPU i nadále sloužit celkem ke spokojenosti...

[little.owl]

Já bych ten Intel hate zas tak nedramatizoval. Ars technica kritizuje Intel PR (pochopitelně), ale AMD PR kritizuje taky a chválí pouze ARM.

Mozna, ale me neslo o PR. Rozdil mezi ARM a Intel/AMD je v tom ze oni neprodavaji koncovym zakaznikum a jejich situace je proste jina. Intel se viditelne pokousel stahnou ostatni s sebou, at jiz na urovni PR, tak pri vyvoji Linux kernelu, takze treba ten kritizovany mail od AMD ci reakci Linuse zcela chapu.

Nic to nemeni na tom, ze lide byli nechani Intelem pul roku v situaci, kdy jim bylo mozne snadno zcizit data. Nikdo z nas nevi kam vsude informace unikla, zpravy o vazne chybe pronikali ven jiz od listopadu a pocet zainteresovanych lidi byl velky. Hadam ze NSA a podobne instituce mely doslova datove zne.

Koupil byste si pred par tydny k Vanocum Intel procesor, pokud byste vedel jaka je situace? Asi spise ne.

Co se týče domácích strojů a workstations, IMHO i přes Meltdown budou Intel CPU i nadále sloužit celkem ke spokojenosti...

Soucasne opravy Meltdown neresi plne podstatu, takze je spise otazkou casu nez se provali dalsi cesta jak tuto HW chybu vyuzit.

[pc2005]

Soucasne opravy Meltdown neresi plne podstatu

Jo tu flushování TLB při každém vstupu do kernelu (tuším?) je nechutný hack a PCID funguje jen na poslední generaci :-/.

[kralyk z abclinuxu]

Nic to nemeni na tom, ze lide byli nechani Intelem pul roku v situaci, kdy jim bylo mozne snadno zcizit data. Nikdo z nas nevi kam vsude informace unikla, zpravy o vazne chybe pronikali ven jiz od listopadu a pocet zainteresovanych lidi byl velky. Hadam ze NSA a podobne instituce mely doslova datove zne.

Omg. Ty jsi zaměstanenc AMD nebo proč furt ten shilling?

Koupil byste si pred par tydny k Vanocum Intel procesor, pokud byste vedel jaka je situace? Asi spise ne.

Spíše ne, ale stejnětak bych si nekoupil procesor od AMD a raději čekal, jak se situace vyvrbí. V roli koncového uživatele pro mě není Spectre o moc méně závažný než Meltdown, viz obligátní xkcd.

[little.owl]

Omg. Ty jsi zaměstanenc AMD nebo proč furt ten shilling?

Nejsem. Ale zazil jsem opatreni ve firmach prijmana po tomto, takze si uz nedelam iluze.

V roli koncového uživatele pro mě není Spectre o moc méně závažný než Meltdown, viz obligátní xkcd.

Tam jde spise o to jak Intel ted ku*vi SW pro vsechny, viz treba shrnuti zde:

Also, all of Intel's press releases on these topics are HIGHLY deceptive. Purposefully deceptive.

First, they try to revector and confuse the issue by saying these bugs cannot modify or delete memory... but nobody was ever saying that. These bugs DISCLOSE protected memory, meaning your cryptographic keys and web sessions aren't safe (among other things). Intel intentionally avoided mentioning that. Intel also didn't mention that Meltdown is essentially a FULL KERNEL MEMORY disclosure bug, and that it is easy to exploit. And that it is Intel-specific due to stupidity on Intel's part.

Intel is also playing up microcode and BIOS updates for these bugs. What they aren't saying is that these microcode updates amount to ONLY minor mitigations of the Spectre bug. There aren't a complete fix to Spectre or anything close. And, more importantly, THE MICROCODE UPDATES DO NOT FIX THE MELTDOWN BUG AT ALL. We kernel programmers have to implement the horrible performance destroying mitigation to workaround meltdown on Intel CPUs.

Intel is also trying to push all sorts of crap onto the programming community. They are pushing hard to implement horrible hacks in GCC and other compilers and are trying to push horrible hacks to indirect procedure calls as a mitigation for spectre. THIS WILL NEVER WORK!!!!!. 30,000+ applications would have to be recompiled with the changes and kernels would have more horribly hacked code pushed into them just to obtain a PARTIAL mitigation.

Spectre can only be completely fixed in hardware.

Intel is intentionally trying to deceive its customers and its audience. It is the WRONG RESPONSE to these extremely serious bugs, particularly to the Meltdown bug.

To say that we are pissed at Intel right now would be an understatement of epic proportions.

[pc2005]

Intel ted ku*vi SW pro vsechny

To není pro všechny. To by v GCC určitě neudělali :-/. Mu daj speciální kompilační flag a konfiguraci v kernelu a pohoda :-P. Akorát pak nepůjde přenést jedna aplikace z nonintel na intel z důvodu bezpečnosti no .

Hmm jak to má vlastně VIA? Vortex je na úrovni 586/486, ten je v pohodě a pak už znám jen mrtvou transmetu :-/. Ale předpokládám, že transmeta by byla dneska vysmátá, kdyby ovšem přežila.

[kralyk z abclinuxu]

To s tou NSA nechápu. Je něco specifického na vztahu Intelu a NSA? Proč by nemohla NSA mít nějakou dohodu s AMD nebo kýmkoli jiným krom Intelu?

Ta citace mi přijde strašně dramatizovaná. Ano, ten PR state Intelu stojí totálně za***no, o tom žádná, ale koho to ještě překvapí? Proto je mimo jiné lepší si přečíst ten jejich whitepaper. Mimochodem, AMD, alespoň co já vím, zatím žádný ekvivalent takového whitepaperu nevydalo. AMD v podstatě akorát víceméně lakonicky napsalo "Nás se tohle netýká. Prostě nám věřte". Přitom v tom Meltdown paperu není nijak garantováno, že se to AMD netýká, pouze píší, že jim útok na AMD nefungoval a ani přesně nevědí proč.

Na mě to dělá dojem, že to, že u Intelu je ten dopad o dost horší, je víceméně náhoda a AMD má víceméně prostě jen kliku.

Co se týče ku*vení SW pro všechny, pokud myslíš PTI, tak to přece uživatele AMD neovlivní. Co se týče přidávání nějakých prostředků proti Spectre - třeba nějakých memory fenců apod. - tak to je potřeba na víceméně všech CPU se spekulativním prováděním.

[pc2005]

Na mě to dělá dojem, že to, že u Intelu je ten dopad o dost horší, je víceméně náhoda a AMD má víceméně prostě jen kliku.

U spectre má AMD prostě lepší architekturu (aspoň podle diskuzí a toho inženýra co požádal o vypnutí KPTI pro AMD). Ale souhlas, je tu trochu tohodle . Ja jsem například na intel naštvaný víc než na AMD a to proto, že všude cpe své procesory (s tím, že jsou lepší než konkurence, což byla pravda), takže teďka mám všude intel s meltdownem. Výš upgradovat nejde, protože Intel mění sockety jak na běžícím páse (protože prý technologický update, což je buď lež nebo nemyslej) a pokud vůbec bude nějaká oprava spectre v mikrokódu, tak jí ani nedostanu (fajn dicontinued, ale tohle je bug ze samotnýho počátku spekulativních operací v x86).

[pc2005]

Zvlášť když si dělaj reklamu z toho, že přijdou i na sebemenší chybku. To je prostě karma .

[MadCatX]

Tak takhle to bylo s tím Meltdownem. "...mu tady ten check změním na no-op, to bude švanda!"

[pc2005]

[Bedňa]

Ja si furt hovorím, že nič nieje náhoda. Zrovna sme viedli debat o Asembleri a špekulívných operáciach na IRC aké je to prevratné a rýchle a BUM :)

Ja už nejaký čas dávam od Intelu ruky preč. Fakt fandím AMD, už len preto, že dokopal tento svet k 64bitu a za ďalšie AMD sa snaží ísť viac k open source. Ich finančné výsledky sú kolísavé, ale nebol by som rád aby tam nastúpil nejaký finančný čistič, ktorý ich uprace a ostane tu len uzavretá 32šmejďárna menom Intel :(

[little.owl]

To s tou NSA nechápu. Je něco specifického na vztahu Intelu a NSA? Proč by nemohla NSA mít nějakou dohodu s AMD nebo kýmkoli jiným krom Intelu?

Kouknete se na co jste reagoval. Ten bug byl bez oprav znam vice nez pul roku pomerne znacnemu poctu lidi, vcetne toho jak ho vyuzit. Myslet si, ze se to nedostalo k agenturam jako je NSA a dalsi je iluze, stejne jako ze toho patricne nevyuzili. Informace mela byt zverejnena drive, Intel to podle vseho blokoval mesice a trvalo dlouho nez pripustil, ze reseni nemaji, takze se ztracel cas. Mam dojem, ze zajem koncoveho uzivatele nebyla priorita, spise zajmy molochu jako Intel, Google, Amazon a dalsi.

Na mě to dělá dojem, že to, že u Intelu je ten dopad o dost horší, je víceméně náhoda a AMD má víceméně prostě jen kliku.

Castecne ano, ale maji ted lepsi architekturu a hlavne pri navrhu neobetovali uplne bezpecnost pro vykon a to platilo uz od K6.

Co se týče ku*vení SW pro všechny, pokud myslíš PTI, tak to přece uživatele AMD neovlivní.

PTI jde nastesti vypnut a stejne tak bych to chtel i pro cast ostatnich opatreni. Jak psal Linus, SW nesmi byt psan v duchu "vsechny CPU jsou totalni sracky", a Intel k tomu ted masivne tlaci a taky to tak castecne bohuzel zkonci - dusledek inteli monokultury.

Co se týče přidávání nějakých prostředků proti Spectre - třeba nějakých memory fenců apod. - tak to je potřeba na víceméně všech CPU se spekulativním prováděním.

Branch target injection je opet problem predevsim Intelu, kompilatory rozumne nebudou umet resit a zkoncime s nejakym heuristickym paskvilem generujicim hacky a stejne se bude muset spousta veci udrzovat rucne v kodu - a s ohledem na miliony radku kodu v tisicich projektech je to nejspise marne. Navic to bude mit meritelne dopady, 1% je odhad pro kernel, u C++ aplikaci to muze byt mnohem horsi. A jak tohle chcete vypnout pro AMD bez prekompilace? Boundary attack/bounds check bypass ma celkem jednoduche reseni a to je jediny problem co AMD a dalsi skutecne maji.

Tohle me dozene k Gentoo, protoze tam mam moznost ovlivnit jak je muj system prelozen.

[little.owl]

Je to tak jak jsem odhadoval a obaval se. K dopadum na C++ aplikace u LLVM patche pro Branch Target Injection:

When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%.

However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline.

Takze pokud to dobre optimalizujete - priohnete pro zmrsene procesory s uzitim PGO - coz se jen tak v dohledne dobe nestane - dopady budou "jen" 5%-10%, a u specifickych aplikaci - jako pixel/image/video processing - vice - ale snad mene nez zminenych 50%. O problemech spojenych se statickym linkovanim radsi nemluve.

[MadCatX]

Až 10% overhead na "dobře vyladěném serveru" zní dost hrůzostrašně a daleko hůře než celý Meltdown. Na druhou stranu se zdá, že retpoline se bude používat jen tam, kde je to fakt nutné (jádro atp.).

[little.owl]

Nevim, ale uvazuje se o nutnosti takto upravit a zkompilovat interprety a JITy, tedy php, python, java, node a dalsi, pripadne plno sdilenych knihoven, a to muze mit celkem rozsahle dopady.

[kralyk z abclinuxu]

PTI jde nastesti vypnut a stejne tak bych to chtel i pro cast ostatnich opatreni.

Jestli jsem to správně pochopil tak na AMD ani není zapnut...

Tohle me dozene k Gentoo, protoze tam mam moznost ovlivnit jak je muj system prelozen.

Dost pochybuju, že by se ti to opravdu vyplatilo vzhledem k overheadu Gentoo, zejména na uživatelských strojích...

[little.owl]

Mne zajima predevsim run-time overhead, nikoliv compile-time overhead.

[Conscript89]

A ani ten compile time overhead dnes uz neni tak hrozny.

[ehm]

No, abys po pár dalších fixech nějakých zranitelností nemluvil jinak.

Nevíte někdo, jak je na tom Debian testing? KPTI bylo backportnuto do 4.14.11, ale v repozitářích je zatím nejnovější 4.14.0-2. Čeká se, až se to stabilizuje v sidu, nebo... ?

Co se týká intel-microcode, je tam verze 3.20171215.1. Jsem zvědav, jestli to obsahuje fix i pro můj procesor (zatím jsem nerebootoval, tj. nezkoušel jsem).

[MadCatX]

Jednotlivé bloby s mikrokódem jsou značeny dle family-model-stepping v hexa, takže se můžeš mrknout do cpuinfo. Tři řady procesorů, co update dostaly jsou zde zmíněné. (Ne)přítomnost KPTI ověříš třeba takto:

madcat@Thora ~ # dmesg | grep "page tables isolation"
[    0.000000] Kernel/User page tables isolation: enabled

[pc2005]

kompilatory rozumne nebudou umet resit a zkoncime s nejakym heuristickym paskvilem generujicim hacky a stejne se bude muset spousta veci udrzovat rucne v kodu - a s ohledem na miliony radku kodu v tisicich projektech je to nejspise marne.

Jo vlastně proprietární software se bude muset brát automaticky jako děravý.

[pc2005]

No on i ten ARM má spectre bug. Ten maj snad všichni. Tam selhali všichni. No a potvrzený meltdown má jen intel, který je největší a nechává si platit za podobné výrobky jako má konkurence větší cenu. Tak holt dostává vyšší díl hejtu. Ale jinak jako jo korporace jsou všichni . Snad jen kromě opensource softcore výrobců, kde si to můžu opravit ručně sám.

By mě zajímalo zda existuje nějaká spekulativní reorder architektura, která je OK.

IMHO i přes Meltdown budou Intel CPU i nadále sloužit celkem ke spokojenosti...

Pokud to všichni updatujou a pak pomalu. Protože spectrem přes JS se dostaneš do systému a meltdownem do kernelu (a asi i ven z VM).

[pc2005]

Škoda že to nenapsali dohromady: "proven robust architecture"

[rogu]

> takže Spectre tam i dál funguje jedna báseň.

Spectre funguje dal vicemene vsude, silne pochybuji ze to lze resit jinak nez novym hardwarem. PTI se vztahuje k druhe chybe, Meltdownu.

[MadCatX]

Částečně to řešit jde a patche na to už jsou pro RHEL k dispozici - viz ten bulletin ve zprávičce - akorát některé z nich vyžadují taky aktualizovaný mikrokód CPU.

[trekker.dk]

Njn, holt slashdot effect Předtím tam byla akorát stránka o tom, že customer portal will be back soon

[snajpa]

Ono ten customer portal je nejpruserovejsi vec, co tam mistni Ops maji na starost. To se sesype uz jenom spatnym pohledem. Malo decentralizovany navrh

[tonda]

Za poslední dny vyšlo už nemálo článků
https://pbs.twimg.com/media/DS8ZlZeVAAIjoAt.jpg:orig