Vážení uživatelé, drazí zákazníci, milí partneři,
děkujeme vám za váš beta testing, který jste udělali za nás. Velmi si vážíme vaší přízně a děkujeme vám za vaši podporu. Nyní je ale beta testing u konce a další zájemce nepřijímáme, takže pokoušet se o zařazení pomocí instalace patche je zbytečné. Slibujeme vám, že celý problém opravíme tak rychle, jak se nám jen bude chtít a odměnou za vaši trpělivost bude nová a vylepšená verze IME zdarma.
Nemusíte nám děkovat, my to děláme pro sebe
Váš Intel
V čem byl problém Intel asi nikdy neřekne, nicméně Linus se k mikrokódu a souvisejícím patchům kernelu vyjádřil nějak takhle: https://lkml.org/lkml/2018/1/21/192
As it is, the patches are COMPLETE AND UTTER GARBAGE.
They do literally insane things. They do things that do not make sense. That makes all your arguments questionable and suspicious. The patches do things that are not sane.
WHAT THE F*CK IS GOING ON?
Zde je mnohem lepší vysvětlení, co ty patche dělají na různých architekturách místo Linusovy tirády "it's utter garbage": https://lkml.org/lkml/2018/1/22/598
Presne viem, pri preklade instrukcie QFMX do mikrokodu pomocou FB LD MC BU KV dochadzalo obcas k subehu s MA MT OV PI CI bez uzamknutia registra LF ... na co ti to je? Ty poznas Intel mikrokod instruction set a sposob prekladu jednotlivych instrukcii? To je cisty bordel ktoremu ak sa nevenujes cely zivot nemas sancu vnimat. Intel to nijako nedokumentuje a nikto nevie co sa za tou prekladovou barierou skryva. Za dalsie pre rozne procesory bude ten mikrokod iny.
Zas bych z toho nedelal raketovou vedu ... vetsina problemu na tyhle urovni je zpusobena casovanim, kazdej tik hraje roli, mno a kdyz do toho hrabnes, a nektery akce zpomalis mozna i o rady ...
To se ti pak proste stane trebas to, ze si nekde po 30 taktech ctes nejaky data, ktery se prece bezne nactou za 10-15 ... ale po uprave za trebas za 26-31. Coz muze znamenat ze na jednom z desitek tisic prubehu tyhle konkretni instrukce ti to padne nadrzku, protoze tam ty data proste nejsou.
Navic vse souvisi se vsim, takze se to muze projevovat trebas jen pri nejaky konkretni sekvenci.
Myslim, ze tato uvaha je "wrooong on so many levels". Inteli mikrokod nie je skolsky seriovy automat, teda aspon by nemal byt. Frontend necha x86tkove "makroinstrukcie" rozpadnut na instrukcie vnutornej mikroarchitektury. Vzhladom k tomu, aka je x86 komplikovana predpokladam, ze potom nasleduje faza optimalizacie (eliminacia load-store parov a podobnych zjavnych volovin) a potom sa to vykonava tak, ako sa vykonava nativny kod na inych out-of-order architekturach. T.j. vec sa vykona vtedy, ked su k dispozicii data. Necakal by som, ze restarty sposobuje taka trapnost ako "toto tunak trva moc dlho a data sa zaseknu na polceste". Problem bude skor v tom, ze niektora zmena za istych okolnosti meni nejaky predpoklad a nejaka cast mikrokodu potom zazenie vnutornu architekturu do necakaneho stavu z ktorej je cesta von jedine skrz restart.
Vzhladom k tomu, ze sa saha do tak fundamentalnych veci ako branch prediktor a branch target buffer su moznosti rozpadu vnutorneho stavu CPU naozaj siroke. Staci ze sa zaviedol novy flag, ktory sa na 99 miestach kontroluje a na stom mieste nie a problem je na svete.
Tak u AMD je struktura mikrokódu částečně známá.
MA MT OV PI CI :-D
Co k tomu rict.
Mozna snad jen: Intel, go fuck yourself :-)
https://memegenerator.net/img/instances/500x/54778752/hey-intel-go-fuck-yourself.jpg
Ja nemam rad sprosti na diskusi (zvlast technicke), ale do haje, meli na to PUL ROKU to odladit a spravit.
Misto toho se tu lepi upgrady microkodu na posledni chvili, pak se zjisti, ze jsou spatne otestovane a musi se stahovat.
Mesic pryc, poradne reseni nikde, systemy derave jak cednik (je fajn, ze tu mame virtualizaci a kontejnery, ze?)
Absolutne nejsem na Intel (kohokoliv jineho) nastvany za to, ze se ten problem stal, ale za ten pristup k nemu...
Zranitelné jsou,
jen Spectre je tam nějak nespolehlivý, asi se nedaří úplně přesně šáhnout na časování a je třeba si pohrát s parametry (a tím nemyslím jen nahrazení instrukce rdtsc), aby se získala správná data. I tak to není úplně 100% . Ale tyto procesory zranitelné jsou.
Meltdown zranitelnost na nich funguje spolehlivě.
Trochu pozdě, ale dík za zprávu. Mě už na PC už update přistál (prý ten "opravený") a windows spáchal sebevraždu. Windows nefunguje, okamžitý restart. Windows.old (prý záloha původní verze) nefunguje, to samé. Pokus updatu o rollback se dostane dál než předchozí varianty, ale po spuštění OS blikne černé okno okamžitě zhavaruje a restartuje (bez varování nebo modré obrazovky). Body obnovy záhadně zmizely (a že jich tam bylo!) a oprava pomocí instalačky nefunguje. PC je naštěstí jen na hry, takže to není taková tragedie.
Mrkvosoftu a Intelu (zmíněný SandyBridge) se povedlo to, co jsem z dlouho odkládal (z lenosti a ze zvyku "nevrtat se v tom, co zatím funguje"). Naštěstí mám z 80% stejný vkus hry, jako vývojáři ochotní podporovat linux.
Já jsem pomocný admin, takže vím jak se to dělá. Odložit nebo vypnout windows update (Win10 na to potřebuje speciální program, pouze win10pro umožňuje odložit aktualizace o 35 dnů) a vše se instaluje, až jsou opraveny opravy oprav a fungují aspoň dva týdny bez katastrofálních zpráv na internetu. Nebo se instalují jen jednotlivé kritické balíčky místo těch kumulativních mega kolekcí. A i přesto nám jeden update loni pokazil jehličkové tiskárny epson (bylo to na bleepingcomputer, když jsem se vrátil z dovolené). V popisu byl tento "feature" zmíněn, ale žádný odkaz na již existující opravu.
Mas recht, admini v korporatu maj vsechny IPcka co maj neco spolecnyho s M$ updatem v sekci banned na firewallech. Kriticky systemy se pak zasadne neaktualizujou a to tak ze vubec nikdy.
Teoreticky riziko napadeni nejaky diry je totiz mnohem prijatelnejsi, nez 100% jistota ze to nejaka aktualizace driv nebo pozdejs naprosto 100% sejme. A ono i obnoveni backupu = nikoli nepatrny vypadek.
Super, pokud máte průběžně aktualizovaný seznam IP adres Windows Update serverů na zakázání, sem s ním. Protože co vím, tak se jejich IP často mění a navíc stále více využívají CDN pro distribuci obsahu.
Spíše se dají zablokovat doménová jména, ale "domácí" řešení jako úprava hosts zabijí wildcardy, které jsou na to potřeba, takže zbývá manipulace DNS (MS na těch doménách prozatím nemá DNSSEC) nebo analýza HTTPS (!) spojení. Nicméně seznam pro W10 jsem taky nenašel, spíše pro starší verze Windows, možná je seznam stejný.
Zbytek hacků (editace group policy v non-enterprise verzích W10, nastavení "metered connection", apod.) není spolehlivý, protože buď je MS zablokoval, nebo stejně stahují "kritické" záplaty bez ohledu na nastavení.
Tak se predpokladam obratis na ten support co mas zaplacenej v cene widli, jak tu pomerne nedavno blabolil lulan a spol. A ten support promptne dorazi, a tvuj problem vyresi ... protoze kdybys mel toho tuxe zadarmo ... tak by sis to musel resit sam (prej).
BTW: Kolegovi jeho znamej prines AMDkocvej komp ... kde ty widle rotovaly boot ... samo po aktualizacich. Mno ... jak by rek lulan, to prece neni zadnej problem, proto si widle schovaj kazdou revizi kazdyho dll ... ale nabootovat do defaultniho stavu nezvladnou. Takze cista instalace a demolice aktualizaci.
Na bricknutý AMD s W7 mi stačil repair disc, ale musel jsem ho nechat "spravovat" třikrát :-D
Poprvé se nestalo vůbec nic.
Podruhé to rozbil ještě víc.
Potřetí to konečně opravil.
Ale mezitím jsem potřeboval dva různé Linuxy, abych tu opravu na té kámošově kraksně vůbec rozjel!
A delals to tejden nebo dva? Jo taky sme na to zkouseli vsemozny opravy .... asi tak hodinu, pak nas to prestalo bavit.
Vubec nejkrasnejsi ale je, kdyz desitky zacnou delat ten svuj uzasnej upgrade ... to ti nejdriv 5, 8, 10 hodin 100% vytizej sit. (pokud by v ty siti tech widli nedej boze bylo vic, tak klidne i mesic(e)). Pak se cosi (i na ssd) nekolik hodin instaluje ... aby ses dozvedel, ze se "neco pokazilo" a nejmin stejnou dobu se bude delat rollback, nacoz zacne druhy kolo.
Vyzera to ze Fedora (po vyhlaseni Intelu ze ich patche su nebezpecne) neponuka microcode_ctl-2.1-20.fc26 a aktualne ponuka predchadzajucu verziu microcode_ctl-2.1-19.fc26. V update repozitaroch ale microcode_ctl-2.1-20.fc26 zostava.
# dnf info microcode_ctl
Last metadata expiration check: 1:11:00 ago on Thu 25 Jan 2018 09:32:28 AM CET.
Installed Packages
Name : microcode_ctl
Epoch : 2
Version : 2.1
Release : 19.fc26
Arch : x86_64
Size : 1.5 M
Source : microcode_ctl-2.1-19.fc26.src.rpm
Repo : @System
From repo : updates