Poslední Intel mikrokódy mohou způsobovat restarty

Podle The Registeru, který se odkazuje na zprávu Intelu, je možné, že poslední aktualizace mikrokódu pro architektury Broadwell a Haswell způsobují náhlé restarty počítačů. Takže pokud jste po aktualizaci zaznamenali nestabilitu systému, je možné, že toto je důvod.

12.1.2018 12:22 | Jaroslav Kucera | Bezpečnostní upozornění

Komentáře

[j]

Tak to je jeste fajn, soudruzi u M$ to vyresili tak, ze s AMDckem to uz nenabootuje vubec .... ;D

[Rezza]

Kdybych se kolem tech CVE obcas nemotal, tak bych se i zasmal. Ale ona to fakt neni sranda reagovat na neco takoveho, co skoci asynchronne do vyvoje, release procesu, planovani atd., s obrim tlakem na rychly fix... A pak se samozrejme stavaji chyby.

[koroptev]

maj to nejdriv otestovat na uzivatelich fedory, tam to neboli

[Rezza]

Ale oni to samozrejme driv nez hobici chteji ti, kterym na tom bezi byznys a za to si plati :).

[Peter Golis]

A to tam nemáte nejaký testovací klaud na zbierke heterogénneho železa, tak ako to robia hobby hostingy z garáže? Teda oni to asi nevolajú testovací, ale entry model s najnižšou cenou...

[Bivoj]

Jo je fakt, že na to měl Intel jen půl roku. Chudinka. Ten nedostatek lidí a peněz je prostě znát.

[koroptev]

mam to vnimat jako plus nebo minus ze jedu na sandy bridge? komplikovane emoce

[TM]

Pravděpodobně nemáte představu, co obnáší práce na větším projektu a kolik je nutno u komplexního systému např. udělat testů. I tak nemáte úplnou jistotu, že jste odhalil všechny možné problémy.
A to jsem si jistý, že vývoj takovýchto CPU přesahuje mou vlastní zkušenost. To opravdu nebude sranda...

[Bedňa]

Pretože sme mali zrovna debat na IRC o špekulatívnych operáciach v Asemblery a do toho zrovna pristála správička o bugoch v procesoroch, tak to rozumne ani riešiť nejde. Proste jedine že sa to komplet odstaví a procesory neprídu o 30% výkonu ale ďaleko viac. Teda z debaty to vyšlo na strátu 70 a viac percent.

[pc2005]

Pretože sme mali zrovna debat na IRC o špekulatívnych operáciach v Asemblery

Jakej kanál, mohu-li se zeptat?

[Bedňa]

To je karma, pretože sa veci nedejú náhodne a posledné dni to fakt priťahujem, alebo je to vyššia moc.

Som štandartne pripojený na cca 10kanáloch a viac, teda sledujem moje obľúbené projekty a komunity.

Začala debata o programovaní, tuším ako prvé to začalo na brmlab o špekulatívnych výpočtoch. Tak nejak som sa zapojil a písali sme si aj na iných kanáloch, tak som to tam možno vniesol ja. Proste to skončilo tak, že ja ako stará škola s jednovláknovým Asemblerom som začal niekoľko diskusií o špekulatívnych výpočtoch, čo vlastne bola pre mňa novinka.

Tak debat na brmlabe skončil a do toho zas na inom kanály, niekto písal, že to Intel dojebal ako to riešil v kaši. Potom som mrkol aj na správičky a vida, bolo to tam :)

Prišlo mi to proste fakt až magické, že na jednom kanály, sa dozviem ako to funguje, potom sa na inom kanaly o tom bavíme asi ja neviem dve tri hodiny a potom, niekto ďalší napíše že to je rozbité.

PS: Fakt neviem či to priťahujem. Vesmír funguje divne a stala sa tento týždeň vec s ktorou nechcem spamavať, ale keby ťa zaujímala, napíšem :) Nemá to nič spoločné s touto témou.

[Radovan]

Náhoda neexistuje. A zákon schválnosti je jediná věc ve Vesmíru, která funguje spolehlivě

Už v Brmlabu začali tavit křemík, nebo to aspoň plánují?

[Agent]

strátu 70 a viac percent

To snad ne, propána.. Myslel jsem si, že out of order architektura se všemi těmi spekulativními vifikundacemi přidá tak tech řekněme 20-40%. Kdyby 50, ale 70? To se vrátíme někam do dob P3. Takový Cell, myslím, nebyl ještě ani out of order a o 70% pomalejší než tehdejší Pentia nebyl.

No každopádně to vypadá, že se možná vrátí časy taktování a honění frekvencí do oblak, abychom to trochu vyrovnali.

[Ovoce]

Takový Cell, myslím, nebyl ještě ani out of order a o 70% pomalejší než tehdejší Pentia nebyl.

Cell měl zvláštní architekturu s osmi koprocesory s omezenou malou pamětí, kterým pokud se podařilo předělit úspěšně práci, tak to mělo velký (aspoň teoretický) výkon. Ale samotné jádro bylo slabé. Mělo to jen jedno centrální CPU, které všechny ty koprocesory mělo krmit a řídit, ale samo o sobě bylo pomalé až hanba, horší než Pentium III bylo celkem určitě. Možná i o těch 70 %.

[pc2005]

Myslel jsem si, že out of order architektura se všemi těmi spekulativními vifikundacemi přidá tak tech řekněme 20-40%.

BTW u DEC Alpha si mysleli že těma vifikundacema dokážou pokrýt overhead x86 emulace.

[Peter Fodrek]

Problem je, ze to nejde otestpovat ani na jenom PC vo vstecky moznych situaciach /stavoch logickeho automatu, a nieto na CPU-cka od rtoku 1995 do roku 2017 od vioacerych vyrobcov...

tak si to spocitajme

Skylake ma najmenej 20 stupnov dlhsej pipeline

3.8 Branch prediction in Intel Haswell, Broadwell and Skylake

Misprediction penalty The branch misprediction penalty varies a lot. It was measured to 15 -20 clock cycles http://www.agner.org/optimize/microarchitecture.pdf

Instrukcii pouzivanych v x86 bolo v roku 2013 cca. 670

teda iba kombinacii rozpracovanych instrukcii je

670^20=3,32x10^56 roznych kombinacii

aby nebolo vplyvnenie, tak musi test trvat min 2x cela pipeline to 40 cyklov. Pri 4GHz trva teda jeden test 10 ns. Kedze nie vsteky instrukcie idu v jednej pipeline pocitajme 1ns.

za sekundu je to 10^9 testov.

den ma 3600*24s rok ma 365*24*3600= 3,15 *10^7 s to da 3,15*10^16 testov za ok

resp. vek vesmiru je cca 13,798 miliardy rokov (4,5354 * 10^17 sekúnd) teda za vek vesmiru sa da otestovat

4,53*10^28 testov

Prakticky by teda plny test len tejto casti Skylake-u trval cca. vek_vesmiru *vek_vesmiru

Takze je nerealne tvrdit, ze sa to da otestovat, a uz vobec nie v tick-tock strategii..

MIPS je RISC aj x86 je vnutorne RISC a navonok je to CISC a poctal som to na CISC x86 instrukcie, co nie je presne, ale orientacne je sedi...

[pc2005]

Jestli není ten update mikrokódu na úkor nějaké předchozí opravy (třeba P3 coppermine bez mikrokódu měl problém dokončit POST), tak by to otestovat mělo jít. Nemusíš dělat všechny možné kombinace, ale po každé mikroinstrukci (těch bude mnohem míň než x86-64 instrukcí) udělat snapshot stavu procesoru a udělat diff oproti předchozí instrukci. Rozdíly mezi mikroinstrukcema by pak měly odpovídat specifikaci.

Nehledě na to, že pokud by se chyba zachytila jenom tím tvým vyčerpávajícím úplným testem, tak to není současný stav. To padání je prý dost častý, takže by to zachytil klasický test na reálném nasazení. Pustit update na nějaké testovací farmě s linuxem a windowsem apod. zvládne i Intel.

[Jendа]

Jak se tohle na widlích vlastně řeší? Na Linuxu dám disk do jiného počítače nebo nabootuju z live, chrootnu se tam a updatnu/downgradnu balíček co to způsobil, ale na Win?

[Jan Zahornadsky]

Najdu někoho, kdo mi to přeinstaluje a obnoví ze zálohy, zatímco si dám kafe?

Trochu vážněji, Windows balíčky novými verzemi nenahrazuje, jenom se na novou verzi přepne (technologie Windows side-by-side a jeden z důvodů, proč zabírá po pár aktualizacích 40+ GB), takže pokud se nastartuje z předchozí funkční konfigurace nebo nouzového režimu, tak by to mělo jít taky přepnout.

[petrfm]

Neměl win nějaké body obnovení? Matně si vzpomínám, že v době wn7 jsem to jednou použil, když se mi zesral systém a nechtěl jsem ho reinstalovat. Vrátil jsem se o týden zpět.

[Max]

Win má různé body obnovení, ale není to tak easy jako u Linuxu a může to skončit opravou instalace.
S Win10 si Win dělají rescue partition na konci disku, má to asi 400MiB a je tam nějaká minimální instalace, která se načte v případě, že systém nenabootuje.
Pokud se systém dokáže načíst do login screenu, tak lze použít podobné fce jako v případě resetu hesla. Tj. přes linux live CD, nebo instalační dvd win lze přepsat soubor s nápovědou souborem cmd.exe a v login screenu ťuknout na help a člověk má cmd se systém právy a může zahájit případné kroky pro nápravu (po opravě pak přepsat zpět souborem s nápovědou).
Zdar Max

[Radovan]

Známý nainstaloval aktualizace na W7 s AMD, a už to nezapnul. Pokaždé to spadlo do BSOD po načtení AtiPcie.sys, žádnou cestou z bootovacího menu se nedalo dostat ani o bajt dál. Pomohl až opravný disk, a tím jsem to musel nechat projet třikrát, než ty Widle najely!

Vylepšení kvality KB4056894 je zrovna teď na netu velmi populární

[Max]

Přitom údajně jde update odinstalovat z recovery console.
Zdar Max

[Radovan]

Četl jsem to a zkusil, i podle redditu, ale zrovna na tomhle stroji prostě neexistoval způsob jak se do nějaké konzole dostat. Zřejmě se to projevuje různě, nezabírá jen jeden zaručený recept ale některý z celé řady různých.

Ona to může být i víc problémů naráz, které prostě soutěží kdo to umrtví jako první. Já jsem tam musel tu opravu nechat proběhnout třikrát, poprvé se nestalo vůbec nic, podruhé se to rozbilo ještě víc, a teprvé potřetí systém ožil!

Tu závadnou aktualizaci jsem nakonec ani nemusel odinstalovat, když se to konečně rozjelo byla označená jako neúspěšná, tak jsem rovnou zakázal automatické aktualizace, dokud se redmondští trochu neproberou.

[koroptev]

pravdpodobne pouzivaji efektovnejsi postup nez pokus/omyl vseho na vsechno; delaji pokrocile veci, tipoval bych, ze jejic nastrojem c 1 bude hlava a ne obscedantni pinktlich beancounter

[NN]

No tvl.

[pc2005]

No jestli nedokázali mikrokód za půl roku vyladit, tak se už nedivím, že ten bug u validace architektury neobjevili od toho pentia pro.

[pc2005]

Bych se nedivil, kdyby ta oprava rozbila něco dalšího, co v intelu příliš zoptimalizovali z důvodu vyššího zrychlení .

[Ivan]

Dobry den prajem, ja mam na PC dualboot Linux a Windows, po zaplatach som sa vcera vobec nedostal do Windows, Linux Mint ide normalne, este ze ten win moc nepotrebujem :)

[2017]

Me na Lenovo Yoga Ubuntu 16.04 LTS:

- prestalo fungovat opakovani stisknutych klaves

- acpi sem tam nereportuje baterku

- smartctl mi uz par dnu hlasi, ze mi do 24hodin prestane fungovat disk

Tak nevim, kde soudruzi v Ubuntu udelali chybu.

Jakoze vysledek upgrade je nakup noveho laptopu!? Jesteze byly volby a mohl jsem slyset naseho nejvetsiho, nejmladsiho, nejzdravejsiho a nejhezciho retora. Jinak by me takova prkotina mohla trosku nazlobit.

Hlavne ze mam v cat /proc/cpuinfo |grep secu bugs : cpu_insecure bugs : cpu_insecure bugs : cpu_insecure bugs : cpu_insecure

Co to vlastne znamena?

Nejde ten interlmicrocode revertovat? jakoze abych zjistil jestli je ten disk fakt v haji nebo si ze mne jen nekdo po ceste k diskovemu FW dela srandu.

[ehm]

Mělo by stačit downgradnout ten balík intel-microcode na předchozí verzi. AFAIK se ten mikrokód nahrává vždy při bootu, nebo jej lze realoadnout příkazem echo 1 > /sys/devices/system/cpu/microcode/reload. Ohledně downgradu konkrétního balíku více třeba tady.

[2017]

diky!

zkusim to. vsiml jsem si, ze to opakovani klavesnice je je zpusobeny tim, ze se odnekud generuje neustale sekvence "^@". lze to poznat prepnutim do textove konzle, kde ten vstup neni "prelozen" Xserverem a u loginu to neustale generuje ^@ akoby zaseknuta klavesa Ctrl+@. Uz jsem to vysal, profouknul a na 99.999999999% je ta klavesnice ok.

Fakt divny. Pred updatem to nedelalo.

[2017]

downgrade kernelu a microcode vyresil klavesnici a baterku.

disk i po trech uspesnych (OK/PASSED) extended seft testech stale premysli o smrti do 24hodin.

tak nevim..

[Conscript89]

Nevim jak to ma Ubuntu, ale pokud to ma stejne jako Fedora nebo RHEL, tak je potreba jeste pregenerovat initramfs.