Aktualizace mikrokódů pro procesory Intel i AMD (diskuse)

[petrfm]

A způsobí to zpomalení, nebo ne? Instalací se tedy definitivně té chyby zbavím?

[little.owl]

Zpomaleni ano, definitivne se te chyby nezbavite.

[insomniac]

Takze win-win?

/s

[lertimir]

Je popsáno jakou část těch chyb se updatem řeší? (když se nezbavíme definitivně) A jaká zranitelnost zůstává?

[little.owl]

Je popsáno jakou část těch chyb se updatem řeší?

IMHO neni, krome novych instrukci, ktere snizi pravdepodobnost utoku, pokud jsou v SW pouzity (pouze Spectre).

(když se nezbavíme definitivně) A jaká zranitelnost zůstává?

Tady se otevrela Pandorina skrinka, podstatu jen maskujeme a dalsi utoky na podobnem principu budou prichazet dokud se neprejde na novy opraveny HW ... .

[little.owl]

Ten list provesoru je zavadejici, neznamena totiz ze CPU dostal update, ale ze jeho microcode je v balicku - i kdyz treba z 2013 jako u SandyBridge E ...

[petrfm]

Když mi ubuntu ve správci SW nabízí update ovladače "microcode Intel" tak to znamená, že pro můj procesor už se dá nainstalovat?

[little.owl]

Updatuje se balicek, ktery obsahuje firmware mnoha procesoru od Intelu. Pokud mate neco novejsiho nez Sandy/Ivy Bridge, update s opravou asi dostanete, pokud starsi bude tam stejny microcode jako mate dosud.

[pc2005]

A Merom C2D zase nic :-P

[Lukáš Zapletal]

Pozor, ty balíky obsahují firmware jen pro malou rodinu procesorů. Takže instalací nemáte nic jistého, je to potřeba pak překontrolovat přes "dmesg". Bacha na to!

[pushkin]

Jakože takhle?

pushkin@pushkin-htpc:~$ dmesg | grep micro
[    1.517627] microcode: CPU0: patch_level=0x0700010b
[    1.517635] microcode: CPU1: patch_level=0x0700010b
[    1.517646] microcode: CPU2: patch_level=0x0700010b
[    1.517658] microcode: CPU3: patch_level=0x0700010b
[    1.517767] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.183297] platform microcode: firmware: direct-loading firmware amd-ucode/microcode_amd_fam16h.bin
[    3.184241] microcode: CPU0: new patch_level=0x0700010f
[    3.185161] microcode: CPU1: new patch_level=0x0700010f
[    3.186064] microcode: CPU2: new patch_level=0x0700010f
[    3.186996] microcode: CPU3: new patch_level=0x0700010f

[Michal Kubeček]

Tak nějak, ale pro fam16h (zatím?) žádný update není, jen fam17h.

[pushkin]

Jo, teď na to koukám - ten odkaz vede na balíček s FW z roku 2016 ("zdrojáky"). Jenom jsem ho až teď instaloval :)

[andrej]

podla releasenote microcode-20180108 (overenene cez diff microcode-20171117.tgz vs microcode-20180108.tgz:) je zmenenych 19 z 94 mikrokodov:

2013 haswell
HSW Cx/Dx       (06-3c-03:32) 22->23
HSW-ULT Cx/Dx   (06-45-01:72) 20->21
HSX C0          (06-3f-02:6f) 3a->3b
HSX-EX E0       (06-3f-04:80) 0f->10

2014 broadwell
BDW-H E/G       (06-47-01:22) 17->1b
BDW-U/Y E/F     (06-3d-04:c0) 25->28
BDX-DE V0/V1    (06-56-02:10) 0f->14
BDX-DE V2       (06-56-03:10) 700000d->7000011

2015 skylake
SKL-H/S R0      (06-5e-03:36) ba->c2
SKL-U/Y D0      (06-4e-03:c0) ba->c2
SKX H0          (06-55-04:b7) 2000035->200003c

2016 kaby lake
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0      (06-9e-09:2a) 5e->80
KBL-U/Y H0      (06-8e-09:c0) 62->80

2017 coffee lake
CFL B0          (06-9e-0b:02) 72->80
CFL U0          (06-9e-0a:22) 70->80

???
Crystalwell Cx  (06-46-01:32) 17->18
GLK B0          (06-7a-01:01) 1e->22
IVT C0          (06-3e-04:ed) 428->42a

format: microarchitecture version (family-model-stepping) old->new

[trekker.dk]

Podle family-model-stepping je to poslední - "IVT C0" - Ivy Bridge EP

[Ovoce]

Jo serverová verze Ivy Bridge měla taky kódové označení Ivy Town, takže i podle toho máte asi pravdu. Vlastně počkat - myslím, že tak se nejmenovalo Ivy Bridge-EP (Xeon E5-2600v2), ale Ivy Bridge-EX tj. verze Xeon E7 (E7-8800/4800/2800v2). Tipuju, že na Ivy Bridge-EP už kašlou, ale Xeon E7 jako mission-critical CPU má delší support a tak pro něj ten ucode vydali?

Ty další dva neznámé čipy na konci budou jednak Gemini Lake (aktuální nejnovější Atomy s jádry Goldmont+: https://www.cnews.cz/intel-uvadi-procesory-gemini-lake-pentia-celerony-s-wi-fi-lpddr4-jadry-goldmont/

A to třetí je asi Crystallwell, tj. označení pro ty čipy Haswell s grafikou Iris Pro a s přídavnou pamětí eDRAM na pouzdru.

[trekker.dk]

myslím, že tak se nejmenovalo Ivy Bridge-EP (Xeon E5-2600v2), ale Ivy Bridge-EX tj. verze Xeon E7 (E7-8800/4800/2800v2)

Ten procesor - family-model-stepping 06-0x3e-04 - je Xeon(R) CPU E5-2609 v2 (formerly Ivy Bridge - EP podle ark)

[little.owl]

Predposledni GLK je asi novy Gemini Lake oznameny pred dvema mesici.

[andrej]

meltdown mitigation:

Upgradol som CentOS-7.4 beziaci na Xenon X5650 (Nehalem/Westmere EP, 06-1A-04 z roku 2010), zdvihlo sa jadro z 3.10.0-693.2.2.el7.x86_64 na 3.10.0-693.11.6.el7.x86_64, mikrokod z 0x15 na 0x16 a meltdown test pise NOT VULNERABLE (pred upgradom a rebootom meltdown test pisal VULNERABLE).

V zozname updatnutych mikrokodov tato architektura nebola, takze bud nerozumiem ako intel robi changelogy mikrokodu alebo to musel byt nejaky starsi upgrade mikrokodu, masina bola instalovana 2017/10, plne updatnuta na CentOS-7.4 latest a odvtedy bezala.

performance:

Testoval som git svn clone task - co je pekny mix lokalneho pocitania (hashing a kompresia v ramci git operacii), lokalneho pristupu na disk (git operacie nad filesystemom) a sietoveho pristupu (sietovo pripojene svn repo). Zbehol som 7x migraciu na kerneli 3.10.0-693.2.2 a 7x na najnovsom kerneli 3.10.0-693.11.6. Rozdiel je 125s vs 146s resp. +16%:

      kernel-693.2.2  kernel-693.11.6   693.11.6 / 693.2.2
real  125.63          146.51            116.61%
user  23.19           32.56             140.39%
sys   69.89           88.78             127.04%

[emir]

Meltdown utok je vyrieseny v Linuxovom kerneli - https://en.wikipedia.org/wiki/Kernel_page-table_isolation (aktualizacie boli uz pred par dnami).

[Petr Tomášek]

ale za jakou cenu?

[pc2005]

Se divím, že to vydávaj až teďka, měli na to tak půlrok od toho blogu a 3 měsíce od google zero.

[Jardik]

Prikaz od NSA

[pc2005]

NSA na to měla ty tři celý měsíce a spíš víc. Mezitím mohli pracovat na mikrokódu.

[Peter Golis]

A Ubuntu? To má stále Intel Microcode 20170707. Teda okrem bionic ktorý má aspoň 20171117, ale bionic ešte oficiálne nevyšiel. Trusty ktorý má podporu ešte vyše roka má Intel Microcode ešte starší, teda 20140624.

[mno-hime]

Je možné, že ten Intelí ucode update obsahuje regrese pro některé druhy hardwaru. Z jádra illumos ho stáhli.

[petrfm]

Jáj more, to je debata jak když se baví blbý s hluchým. Tak řeší ta oprava něco, nebo ne? Týden se tady probírá největší průser v historii IT, abychom zjistili, že apt-get upgrade vyřeší hovno a chyby, které inženýři týden lepili a jejichž výsledkem je nový microcode jenom maskuje nemoc HW a za týden se objeví dalších 10 způsobů jak tu chybu zneužít? Má vůbec smysl ten systém aktualizovat, nebo jsem na tom stejně jak ti, co používají W98?

Připadá mi, že se všichni před týdem plácali do stehen jak je intel v prdeli a AMD na koni, ale teď tady máme update pro Intel a mimo jiné AMD a záhy zjistíme, že všechny počítače bude nejlepší vypnout, protože kritické chyby byly nalezeny také v obvodech MH7400?

Existuje někde nějaká seriózní zpráva JAKÉ procesory jsou postiženy, jaké OPRAVY jsou k dispozici, nebo všichni čekají až někdo něco zjistí? Celkem mě zaráží, že nikde nečtu o nějakých případech zneužití... čím to je?

[MadCatX]

Meltdownem je postižené všechno od cca. Core2Duo výše, řeší to patch pro jádro a pro lém má je Intel. Spectre není nějaká konkrétní zranitelnost ale celá kategorie způsobů, jak útočit na out-of-order CPU. Nějakým zpúsobem jsou vyjma x86 CPU postižené i ARMy, POWER atp. Určité konkrétní typy Spectre útoků se snaží řešit kombinace jaderných patchů a nového mikrokódu.

O případech zneužití se asi těžko dočteš. Jednak je téměř nemožné odhalit, že ti někdo přečetl privátní klíč zrovna Meltdownem, druhak technické podrobnosti nějakého útoku se zpravidla zveřejňují až poté, co je úplně vyšetřen (pokud se vůbec zveřejní).

[Jaroslav Kucera]

Zjednodušeně, Intel postihuje Meltdown i Spectre. Meltdown řeší kernelový workaround s velkým dopadem na výkon. Spectre postihuje vše co má podporu spekulativního provádění instrukcí (tj. od Pentia Pro výše) a je pro něj třeba updated microcodu CPU.

Meltdown fix může mít zásadní dopad na výkon (čím víc I/O, tím hůře). Spectre fixy mají dopad mnohem menší.

Než budou známy nějaké případy zneužití, bude to dost trvat. Pokud je/byl útočník šikovný, tak jen krade citlivá data a nedělá žádné změny v systému, které by šlo detekovat. Stačí, že má uživatelské oprávnění na ten systém. A pokud se útok prokáže, firmy se tím určitě nebudou chtít chlubit, nebo alespoň ne hned a dobrovolně. Na Meltdown existují docela hezká dema ( https://meltdownattack.com/ ).

Podle relnoty k Intelu jsou opravené poslední generace. Nejstarší je Ivytown (Ivy Bridge-EX = Xeon E7v2). Tj. klasické Sandy/Ivy Bridge ještě oficiální fix (microcode) na Spectre nemají. Podle oficiální zprávy AMD zatím vydalo jen microcode na generaci 17h (Ryzen/Threadriper/Epyc). Další generace by měly dostat fix v následujících týdnech.

[Hlípa]

Nové microcody, zavádějí pouze nové vlastnosti, které musí vývojáři kernelu a různých VM naimplementovat, aby se účině bránili útokům spectre varianty 2. Zavádí se IBRS (Indirect Branch Restricted Speculation), STIBP (Single Thread Indirect Branch Predictor) and IBP ( (Indirect branch prediction barrier), nové MSR (Machine Specific Registr), které musíte různě nastavovat při context switchy atd.

Problémem je, že podle toho co ten procesor umí se liší oprava a fungování těch branch bariér, takže pak musíte řešit v kódu, na kterém procesoru běžíte. U některých procerů musíte explicitně zavolat 32xCALL aby se vyprazdnila BPT a tak podobně. Samozřejmně všechny tyto opravy mají performance impact.

Ta varianta dva se da vyřešit i bez aktualizace mikrokódu, takzvanou retpoline, jenže to vyžaduje rekompilovat kód upraveným kompilátorem a samořejmé repoline je také drahá.

Obecně problém je pak vyhledat všechny potencionální místa, kde ten problém nastavá a opravit je.

Co se týče Spectre varianta 1, tak tam jediná oprava je upravit opět všechny nebezpečná místa, tak aby nedocházelo k predikci. Nicméně pokud se jedná o sandboxing jako JS, tak tam se to jednoduše obecně vyřešit nedá.

[petrfm]

Díky moc za hezké odpovědi, které by vydaly na krátký článeček, popisující daný problém bez zbytečných technikálií. Ve zkratce lze tedy říci, že je vlastně úplně jedno, jestli nějakou aktualizaci instaluju nebo ne. Kdo chce, najde si způsob i potom a běžný útočník se do systému nedostane a když ano, může zneužít jinou bezpečnostní díru, je to tak?

Jak se dá ten útok PRAKTICKY zneužít? Teorii nechme stranou. Je to tak, že zvenčí je ta zranitelnost bez možnosti zneužití? Pouze pokud mám práva k systému tak dokážu přečíst chráněná data? Ale na útoky třeba po síti to nemá vliv, je to tak? Pokud nenainstaluji nějaký škodlivý SW, tak jsem v bezpečí? Dokud není útočník v systému, nedá se ta chyba v podstatě zneužít k získání přístupu dovnitř?

[MadCatX]

Meltdown i Spectre se dají zneužít i šikovně napsaným JavaScriptem běžícím v prohlížeči. Byl třeba předveden útok, kterým bylo takto možné přečíst databázi hesel uložených ve Firefoxu. Je to právě ta vysoká míra zneužitelnosti, kvůli které zejména Intel panikaří až tak, že vydává rozbitý mikrokód.

[petrfm]

Ale pokud se nepletu tak tohle už je opraveno v kernelu ne?

[MadCatX]

Meltdown ano, Spectre ne, protože to bez úpravy hardwaru nejspíš nepůjde. Nevím, jaká je proveditelnost Spectre útoků přímo z JS ale v podstatě jakýkoliv kód, který nepochází z důvěryhodného zdroje je stále potenciálně nebezpečný.

[the.max]

všechny počítače bude nejlepší vypnout, protože kritické chyby byly nalezeny také v obvodech MH7400?

+1

[pc2005]

Tak ono to není zas až tak nerealistický (badFET attack) .