Velký průšvih s procesory Intel? Prý se tajně chystá bezpečnostní patch snižující výkon

121

Sotva začal nový rok, je zdá se na stole závažná šlamastika. Během včerejška se totiž začaly šířit zprvu kusé informace, dle nichž byla v procesorech architektury x86 objevena závažná bezpečnostní chyba spočívající na hardwarové úrovni, kterou budou muset řešit aktualizace operačního systému. V informacích zatím panuje značný chaos, ovšem podle všeho jsou chybou postiženy všechny procesory Intelu z posledních let, zatímco AMD možná nikoliv. Kromě bezpečnostního rizika u neaktualizovaných systémů je tato chyba závažná ještě tím, že protiopatření údajně zhorší výkon procesorů.

 

Bezpečnostní problém ve všech procesorech Intel?

Následující informace jsou zatím nedostatečně potvrzené, tudíž je ještě berte s rezervou. Ona chyba, která by podle souboru dílčích útržků měla v procesorech Intelu být, se zřejmě dotýká TLB procesoru a zřejmě spočívá v tom, že CPU při spekulativním vykonávání kódu může ignorovat oprávnění. To znamená, že kód s běžnými oprávněními se může dostat k paměti s vyššími privilegii, zejména do kódu a datových struktur jádra operačního systému. Jde o zásadní bezpečnostní problém na serverech, ale i na běžných počítačích.

Tuto chybu má zřejmě záplatovat změna správy virtuální paměti, na níž se posledních pár měsíců pracovalo v Linuxu, ale údajně i ve Windows. Jde o oddělení adresních prostorů uživatelského prostoru („userspace“, tedy paměť pro běžné programy) a jádra čili operačního prostoru. Ty byly doposud kvůli výkonu mapovány společně. To má tu zásadní výhodu, že v TLB bufferu procesoru mohou zůstat cachovány informace o tom, která stránka virtuální paměti je namapována na které místo fyzické paměti. TLB je kritický pro rychlost operací s pamětí – jeho chyba v procesoru Phenom revize B2 v roce 2008 vedla po opravě k velkým propadům výkonu.

Během podzimu byla však do Linuxu implementována izolace adresního prostoru jádra od uživatelského prostoru pod označením PTI nebo KPTI (Kernel Page Table Isolation, dřívější vývojové označení bylo KAISER), která oba prostory oddělí – prostor jádra již nebude namapován v adresním prostoru uživatelských procesů jako doposud. Podobná změna je údajně separátně implementována ve Windows 10. Prý by mohla vyjít v rámci lednového záplatovacího úterý a již je v sestaveních „fast ringu“ pro členy programu Windows Insider.

intel-coffee-lake-core-procesor-lga-1151-1600

Jak to souvisí s Intelem? Zdá se, že tyto změny správy virtuální paměti (což je zásah do základů systému, který obvykle bývá podnikán se značnou rozvahou a dlouhým testováním) byly učiněny poměrně nakvap kvůli tomu, že jsou potřebné právě pro obejití oné hardwarové slabiny, kdy se proces bez privilegií může dostat do paměti jádra. Oddělení adresního prostoru by tomu mělo zabránit. Patche pro Linux jsou zde, kvůli informačnímu embargu mají ale zatím vycenzurované komentáře a dokumentaci.

PTI znamená zpomalení systémových volání

Problém ale je v tom, že implementace této změny má – což je potvrzeno – zásadní dopady na výkon. Ty se projevují tehdy, pokud vykonávání kódu přeskakuje z programu do kódu v jádře, což je zejména při obsluze systémových volání – například čtení z disku, komunikace po síti, přerušení. Při neizolovaném adresním prostoru mohl takový požadavek proběhnout a vrátit se do programu jednoduše. Nyní ale bude nutné při přechodu tam i zpět vyprázdnit TLB kvůli přechodu do druhého adresního prostoru. Výkonnostní cena systémového volání se tak může přiblížit tomu, co dosud stál tzv. context switch, tedy přepnutí z jednoho programu do druhého.

A momentálně to vypadá, že kvůli oné údajné zranitelnosti procesorů Intelu bude v Linuxu (ale možná i ve Windows) izolace adresních prostorů zapnuta ve výchozím stavu, takže se tyto propady projeví všem uživatelům, kteří operační systém adresují. Nemá se to přitom týkat jen aktuálního Linuxu (nadcházející verze 4.15), PTI bylo backportováno i na větve 4.9 a 4.14, což opět může o něčem svědčit. Výkonnostní dopad zatím není moc jasný kromě toho, že existuje. Mikrobenchmarky měřící přímo dopad výkonu systémových volání ukazují zhoršení o desítky procent (o třetinu až i polovinu), v běhu běžného programu by tyto dopady asi měly být rozředěné. Očekávat by se asi dalo typické zpoždění v jednociferných procentech, ale projevy se pravděpodobně budou značně lišit podle povahy operací. Úlohy s velkým množstvím systémových volání (například příkaz dd na Linuxu) budou mít zásadnější zpomalení. Nezbude než počkat na benchmarky.

Test propadu výkonu v databázi PostgreSQL (zdroj)
Test propadu výkonu v databázi PostgreSQL (zdroj). Výkon procesoru Skylake klesá o 7 až 17 %

Pravděpodobně bude minimálně na Linuxu možné tuto opravu vypnout, ovšem půjde asi o bezpečnostní riziko – jak velké, zatím těžko říct. Možná bude akceptovatelné na desktopu a běžném (třeba herním PC). Na serverech si ale provozovatelé nebudou moci něco takového dovolit. Zda bude funkce PTI přes snížení výkonu ve výchozím stavu zapnutá na desktopových distribucích Linuxu a zda bude tato technika globálně zapnutá i na Windows 10, zatím není jisté.

Efekt opravy podle testu Phoronixu (více zde): Kompilace kódu trpí, naopak x264 nebo FFmpeg (kód silně vytěžující čistě CPU s nízkým podílem systémových volání) zdá se příliš nezpomalil
Efekt opravy podle testu Phoronixu (více zde): Compile Bench obnáší I/O a trpí, naopak x264 nebo FFmpeg (kód silně vytěžující čistě CPU s nízkým podílem systémových volání) zdá se skoro nezpomalila

Vyhnul se problém procesorům AMD?

Izolace adresních prostorů byla zpočátku při vývoji zapnutá jak pro Intel, tak pro AMD. Minimálně podle některých interpretací však zranitelnost, kvůli které bylo PTI vyvinuto, není součástí přímo instrukční sady x86, ale jen architektury novějších procesorů Intel (patrně Haswell, Skylake a novější, možná i starších). AMD zaslalo do jádra Linuxu patch, dle kterého příslušnou zranitelností netrpí, PTI tedy nepotřebuje a může na jeho procesorech být vypnuto.

Podle AMD nejsou jeho procesory zranitelné jako ty od Intelu a PTI by u nich mohlo být vypnuté, pokud bude tento patch přijat
Podle AMD nejsou jeho procesory zranitelné jako ty od Intelu a PTI by u nich mohlo být v Linuxu vypnuté, pokud bude tento patch přijat. Zda se propadu výkonu vyhnou i na Windows, zatím nevíme

Zda ale bude tato změna přijata a AMD dostane výjimku, zatím také není jisté (pokud by ji nedostalo, můžete PTI ještě ručně vypnout volbou -nopti), stejně tak není jasné, zda dostane výjimku na Windows. Nicméně pokud se toto potvrdí, pak by mohla nastat situace, kdy výkon prakticky všech Intelů klesne, zatímco u procesorů AMD zůstane stejný, a tedy budou proti konkurenci relativně rychlejší než dříve. Ovšem opět opakuji, bude třeba počkat, až se všechny momentální nejasnosti lépe ozřejmí. Podobě zatím není jasné, kterých procesorů Intel se bezpečnostní problém týká, pravděpodobně ale minimálně všech současných a zpětně snad i Sandy Bridge, Ivy Bridge, možná i dřívějších.

Aktualizace:

Zdá se, že výjimka z PTI pro procesory AMD prošla do hlavního repozitáře Linuxu (snad má směřovat do jádra 4.15rc6), pokud se nemýlím. Výkonnostní dopad by tedy pro čipy AMD minimálně na Linux být neměl, u Windows stále není jasno.

Víc informací snad už brzy

Zveřejnění této bezpečnostní chyby pravděpodobně nastane během několika dní. Máme o tom indicie například ze strany Microsoftu, který začal uživatelům cloudu Azure rozesílat zprávy sdělující, že 10. ledna bude instance běžící na něm restartovat kvůli bezpečnostním aktualizacím. Něco podobného údajně bude i u IBM a u Amazonu a na 4. ledna údajně vyjde i nějaké „Security Advisory“ od Xenu, které by se mohlo týkat tohoto problému. Opravy a přípravy na jejich nasazení probíhají pod informačním embargem, což by mohlo indikovat, že potenciální problémy nejsou malé. Po zveřejnění detailů by zřejmě mohlo být více jasno v tom, jak moc se nás opravy a propad výkonu dotknou a snad také v tom, zda opravdu budou postiženy jen procesory Intel.

Oznámení Microsoftu, dle kterého budou kvůli nasazování opravy do provozu restartovány instance cloudu Azure
Oznámení Microsoftu, dle kterého budou kvůli nasazování opravy do provozu restartovány instance cloudu Azure

Staré recenze přestanou platit

Zvlášť pokud by se potvrdila domněnka, že procesory AMD opravu nepotřebují (v kterémže případě doufejme pro ně nebude vynucována), vznikne docela prekérní situace u existujících recenzí a testů výkonu. Ty pořízené na starších operačních systémech s exponovanou zranitelností už nebudou reprezentovat skutečný výkon na počítačích s opravou. Mezi jednotlivými opatchovanými procesory se také mohou měnit relativní rozdíly výkonu, pokud na některých architekturách postih bude nižší, než na jiných. V podstatě asi bude třeba vše přeměřit a starší testy procesorů lze hodit do koše. Pro definitivní závěry ovšem vyčkejte, až bude vše zveřejněno a dovysvětleno, musíme opět zopakovat.

Velký průšvih s procesory Intel? Prý se tajně chystá bezpečnostní patch snižující výkon

Ohodnoťte tento článek!

121 KOMENTÁŘE

    • Kernel urcite nebude bezat vo virtualnej pamati, virtualka na to nema ziaden vplyv. Oddelenie adresneho priestoru jadra a uzivatelskych procesov nie je kvoli kapacite, ale kvoli bezpecnosti. Pokial proces nemoze mat svoj adresny priestor a zaroven pristup do adresneho priestoru jadra, musi pri kazdom systemovom volani alebo preruseni prepnut kontext na kernel a spat a to bude drahe.

        • A jak to chceš řešit ještě jinak, než vypnutím prediktivní technologie v CPU (přechod na in-order zpracování je IMHO ale ještě horší řešení)? Jediné další myslitelné řešení je právě na bázi mikrokódu a omezení přístupu k TLB – pokud je ta chyba takového charakteru, že to opravit jde (podobně to řešilo AMD u Phenomů Steppingu B2 a následně hardwarově u B3), ovšem toto „řešení“ odpovídá prakticky oněm patchům do jádra – alespoň jak jsem to po zběžném prostudování pochopil.

          • Peknej FUD. Vubec neni jiste, jakych procesoru se to tyka. Mozna se to netyka Ryzenu, mozna se to take ale tyka jen starsich Intel CPU nebo i AMD CPU. To zatim nic oficialniho venku neni. Ty testy ukazuji jen to, jake rozdily by byly mezi vypnutym a zapnutym PTI. Nerikaji nic o tom, jestli jsou dane procesory ovlivneny tou chybou.

          • Dokud nebude indikace na opak, tak čekám že se to týká i všech aktuálních. Kdyby to třeba v Coffee/Cannon bylo už opravené, tak to by znamenalo, že o tom Intel věděl už třeba před dvěma lety a zatajil… to by byl docela průšvih. Spíš si myslím, že to bylo odhaleno tak před pár měsíci a nastal turbo sprint k tomu sw workaroundu. V jakém stádiu je třeba Ice Lake a jestli sithnou fix, to si úplně „spočítat“ netroufám, to by třeba už mohlo být opravené, podle toho, kdy vyjde.

          • Mezi jednotlivymi generacemi CPU se vylepsuje zabezpeceni zcela bezne a my se o tom ani nedozvime. V tuhle chvili je to moc predbezne. Bezneho desktopu a her se to tak jako tak netyka. V serverech uz to bude horsi a tam si myslim, ze Intel (a ostatni postizeni vyrobci) svoje ovecky davno informovali.

          • @Maudit..chapes chlape rodil mezi Bugem a vylepsenim? Zkus se trochu podivat, co je povazovano za Chybu a co je vylepseni v dalsi verzi.
            Tady se nejedna o vylepseni, ale zaplatovani docela pruserove chyby.

          • Maudit: ale není.

            V tom článku, který odkazuješ, se jasně píše, že na Meltdown není AMD náchylné.

            Náchylnost je až na útok Spectre, který je ovšem „další level“ – nejedná se o chybu v pravém slova smyslu, ale o zneužití funkce out-of-order exekuce (ne že by to taky nebyl průšvih, ale nemá to přímou souvislost s chybou v Intelích CPU).

            viz:
            „Meltdown [27] is a related microarchitectural attack
            which exploits out-of-order execution in order to leak
            the target’s physical memory. Meltdown is distinct from
            Spectre Attacks in two main ways. First, unlike Spectre,
            Meltdown does not use branch prediction for achieving
            speculative execution. Instead, it relies on the observa-
            tion that when an instruction causes a trap, following in-
            structions that were executed out-of-order are aborted.
            Second, Meltdown exploits a privilege escalation vulner-
            ability specific to Intel processors, due to which specula-
            tively executed instructions can bypass memory protec-
            tion. Combining these issues, Meltdown accesses kernel
            memory from user space. This access causes a trap, but
            before the trap is issued, the code that follows the ac-
            cess leaks the contents of the accessed memory through
            a cache channel.
            Unlike Meltdown, the Spectre attack works on non-
            Intel processors, including AMD and ARM processors.
            Furthermore, the KAISER patch [19], which has been
            widely applied as a mitigation to the Meltdown attack,
            does not protect against Spectre.“

          • What is notable, however, is that Intel isn’t the only one affected. Google said that these vulnerabilities “affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.” The company’s security team added that the flaws were first identified last year and the industry has since been scrambling to patch it. Originally, the details of these security issues were supposed to go public on January 9. However, thanks to growing speculation about the issues and the expected heightened risk of exploitation, full Project Zero report has now been made available to the public.

          • gogo: no vždyť. Na Meltdown jsou už venku tooly, tudíž problém eskaloval (a týká se výlučně Intelu).

            Oproti tomu Spectre souvisí s návrhem a způsobem, jakým funguje out-of-order implementace v procesorech, jednoduše řečeno, byla nalezena potenciálně zneužitelná chyba návrhu (jejíž potenciál je ovšem velmi malý a obtížně zneužitelný).

            Stále platí (podle toho, co je známo), že problém má především Intel.

    • „co vypnout virtuální paměť?“

      To nejde, na virtuální paměti je závislej každej moderní OS (Win NT, Linux, Os X, cokoliv), je to nejdůležitější bezpečnostní vlastnost PC. To bychom se museli vrátit do doby Win98/Apple OS 9 a Amigy – byla by to katastrofa i pro stabilitu softwaru, zase by jedna špatná aplikace dokázala rozstřelit celej běžící systém i OS.

      To už by bylo o dost lepší běžet s tou bezpečnostní dírou.

      P.S. Virtuální paměť nemá nic společného s virtualizací, používá se pořád pro abstrakci a ochranu paměti procesů.

      • Apple uz niekolko rokov srvre nerobi, tak az taky velky problem to pre nich nemusi byt.

        Jedna vec je zranitelnost ako taka a druha vec je, ci sa niekto pokusi zneuzit tu zranitelnost. Apple kontroluje vsetky programy pre iOS a pouzivatel si moze zapnut obmedzenie iba na programy skontrolovane Applom pre macOS. Alebo na programy podpisane nejakym vyvojarom registrovanym Applom.

        Takze na Iphonoch a iPadoch treba nastavit testovanie kodu, aby v nom neboli nejake pokusy ziskat pristup do pameti, ktora mu nepatri.

        NA macOS to moze byt problem, ak chce pouzivatel pouzivat programy z neznamych zdrojov. Dufam, ze Apple da na vyber pouzivatelom, ci chcu vyssiu rychlost alebo bezpecnost.

        • 1. nejde jen o servery – tam se zpomalení jen nejvíce projevuje
          2. nejedná se o „zranitelnost“ softwaru, ale chybu v procesoru. Problém může nastat i v okamžiku, kdy je např. v prohlížeči spuštěna speciálně připravená stránka, a to přesto, že prohlížeč na žádnou „závadu“ netrpí. Ze stejného důvodu je taky naprosto liché očekávat nějaké výsledky od kontroly, zda software sahá jen tam kam má.

          • Je to přinejmenším privilege escalation z uživatele na roota (administrátora/kernel), takže to otevírá i riziko napadení osobního počítače. Nevím jestli zrovna i z javascriptu na webu, tak moc do toho nevidím, ale minimálně může nějaký nenápadný program infikovat systém, aniž by ho zastavil UAC prompt.

          • Ja mam macbook pro so 4 jadrovym skylake procesorom. Ak sa mi ma znizit vykon o 30%, tak to radsej ani nebudem instalovat. Dufam, ze Apple ponecha taku moznost. Nerobim na nom nic take, preco by som potreboval maximalnu bezpecnost.

          • Z popisu chyby vyplývá, že problém nastane zejména v případě používání systémových procesů, tj. obecně při komunikaci s hardware. A patrně taky při intenzivnějším multitaskingu, kde musí kernel hlídat priority procesů. Zasaženy tedy budou zejméns server-like nasazení s více spuštěnými aplikacemi, spíše na méně jádrových CPU než na vícejádrových. Např. problémy u kompresních programů a kompilací software jsou způsobeny intenzivním přístupem k disku, problěmy Postgre pak tím, že nemá vlastní cachovací algoritmus, ale spoléhá na cachování OS (pokud to nezměnili, delší dobu jsem ho nepoužil).

            Typické desktopové úlohy asi tak zasaženy nebudou, zejména ne takové, které jsou výpočetně náročné. Pokud ale na desktopu třeba hrajete a zároveň na pozadí komprimujete, k měřitelnému zpomalení patrně dojde.

  1. Tak že pokud se to prokáže a budu si chtít koupit procesor nejnovější generace kvůli výkonu zaplacením částky za kterou se teď pohybují tak bude snížen výkon kvůli nějaký chybě výrobce? To je hezký teda. Vlastně zaplatím za prezentovaný výkon který bude uměle snížen.

  2. Jen houst a vetsi kapky. Ze jsem se zblaznil? procesory a jejich podpurny aparat narostl natolik, ze je v podstate nemozne uhlidat i ty velke bezpecnostni chyby. Jak dlouho trvalo, nez se prislo na tohle – ma to byt jeste pred sandy bridge? Kolik toho tam jeste zbyva? To se samozrejme netyka jen intelu, ale amd i armu, viz nedavne chyby ve Snapdragonu. Chce to poradny pruser, zaloby a rev, jinak budou korporace na zabezpeceni kaslat dal a pridavat dalsi balast, misto zprehlednovani, odlehcovani, modularity umoznujici vypinat nepotrebne atd.

  3. Tyka se to i serverovych cipu?
    K dohledani jsou nejake testy Progress DB s a bez patche a tam se to projevuje okolo 7%, u jinych DB jsou taky vykonove rozdily. Tohle by mohlo byt pro intel dost kriticke, protoze se to tyka firemni a profi sfery.

  4. Pokud se to potvrdí, myslím, že Intel může čekal pěknou hromadnou žalobu, která by ho mohla stát několik let zisků.

    Tyhle průšvihy se opakují, naposledy před rokem se Intel ještě dokázal vykašlat po fiasku s umírajícím Atomem C2000 na všechny, kteří už neměli výrobky s tímto defektním produktem v záruce. Uvidíme, jak se k tomu postaví teď. Minimálně ale image kvality Intelu v posledních letech velmi utrpěla.

    • Pro Intel muze byt pruser hlavne firemni a profi sektor. Na desktopech to vypada, ze se zadne drama nedeje. Ale napr. databaze v produkcnim nasazeni, ktere klesne vykon o radove 5%.. to uz muze byt pruser. Kazdopadne, to bude nahravat i novym AMD Epicum, protoze to zaclouma s duverou v Intel, jak spravne pises.

    • Takovéhle errata nebo problémy se můžou stát i při nejlepší vůli, podle mě. Takže osobně bych si asi nepřál nějaké velké rány, protože to se může stát každé firmě a byl by to asi nebezpečný precedent. Menší hráče by pak mohla jednorázová smůla zlikvidovat (myslím typu AMD, VIA, Cavium, ale možná i Qualcomm nebo Mediatek by to mohlo dostat do problémů, ještě by třeba byli nuceni k nějaké fúzi nebo škrtání a ve výsledku by to byla technologická škoda).

      • I v českém právu jde o problematickou situaci. Občanský zákoník říká:

        § 2095
        Prodávající odevzdá kupujícímu předmět koupě v ujednaném množství, jakosti a provedení. Nejsou-li jakost a provedení ujednány, plní prodávající v jakosti a provedení vhodných pro účel patrný ze smlouvy; jinak pro účel obvyklý.

        § 2099
        (1) Věc je vadná, nemá-li vlastnosti stanovené v § 2095 a 2096.

        Tedy pokud si koupím procesor X, můžu od něj očekávat výkon Y – tj. výkon vhodný pro můj účel (jinak bych si koupil jiný procesor). Pokud najednou procesor nemá očekávaný výkon Y, může to být interpretováno jako vada předmětu koupě a já díky tomu můžu získat práva. Pokud to bude podstatné porušení smlouvy, což nepochybně bude, protože výkon je elementární vlastnost procesoru, pak to vede k možnosti odstoupení od smlouvy.

        Intelu přeju, ať se jim situace vymstí. Sám jsem se stal obětí fiaska Atomu C2000, kde jsem zakoupil serverovou desku a ona těsně po tříleté záruce zdechla. Přitom Intel musel o zvýšených počtech reklamací vědět v té době už dva roky (zvýšená kazivost Atomů se projevovala už po roce a půl), ale snažil se situaci ututlat, aby nemusel platit. Nepřijde mi v pořádku uvést procesor, zjistit, že všechny jsou vadné a všechny umřou dříve, než morálně zastarají, ale dát od toho ruce pryč a nemít se k odpovědnosti. To svědčí o dost pokřivených morálních zásadách. Je chyba Intelu, že vydal vadný produkt, měl mít lepší kontrolu kvality.

        • A že nikdo nezažaloval Mikrosoft, ze občanů, kterých se občasnský zákoník týka, za to všecko co podělali. Aha. Je to nesmysl. A co se týká Intelů v profi korporátní sféře týká, tak tam se dost často ani Intel ani Mikrosoft ani Linux nepoužívá, ale tam už jsou dost vendor specific a custom hardware a systémy – například IBM POWER systémy s PowerPC procesory a operačním systémem AIX – teda pokud se budeme bavit o opravdu rychlých databázových nasazeních pro desetitisíce uživatelů.

          • Software se licencuje, nekupuje. Z OZ se pro licence použijí par. 2359 a také 2371. Jde o úplně jiný právní režim než u koupě hmotné movité věci.

            A i kdybyste tomu nevěřil, doporučuji přečíst si o žalobách Dieselgate nebo teď o žalobě kvůli zpomalování iPhonů. Zvykové právo USA obecně ještě víc chrání zákazníka než právo kontinentální.

          • Ano, software se licencuje, ale pokud sis koupil Windows Phone (třeba ten přímo od MS) a zásah v operačním systému bude mít za následek hardwarový propad výkonu. Vždyť i v procesoru je kód, který si s procesore nekupuješ, ale máš maximálně zakoupenou nevýhradní licenci. Firmware, mikrokód a všecko co je v zařízeních zakoupením výrobku tvoje není pochopitelně.

          • Software si ale licencuje výrobce zařízení, nikoli já. Prodejce mi prodal procesor – věc movitou hmotnou. Žádnou licenční smlouvu jsem k němu nepodepsal. Smlouva je dvoustranný právní akt, to bych musel vědět. Pokud má věc cosi v sobě, co vyžaduje licenci (a nejde jen o software, ale i třeba průmyslové vlastnictví, patent), je starostí výrobce si to zařídit. Následně výrobce věci odpovídá za vady použité součásti. Asi jako když vám prodají auto s vadným airbagem – je to problém výrobce auta, a to i když airbagy sám nevyrobil. Výrobce auta (přesněji prodávající) musí zařídit soulad předmětu koupě s kupní smlouvou, tj. soulad se zamýšleným účelem (tj. že airbag funguje korektně). Jak si to vyřeší se svým dodavatelem, už je jeho problém.

            Pokud je věc jen dodávána společně s jinou věcí, což je případ třeba notebooků s předinstalovanými Windows, nikdo vás nemůže nutit takovou druhou smlouvu akceptovat a musí umožnit používání věci i s jiným software. Microsoft to sice nevidí rád, ale refund v takových případech dělal na vyžádání běžně.

          • Za prvé, rozumím tomu kam míříš a souhlasím s Tebou, nicméně… ano, ale ten výkon snižuje správa paměti, nikoliv hardware. Touto chybou navíc trpí všechny procesory, ne jen Intel, ten však nejvíc. Jak můžeš říct, že někdo něco dělal záměrně špatně, když to tak dělali všichni a nikde nebylo deklarované, že to tak nebude. V právním světě platí, že co nebylo deklarovanáno nemusí být garantováno. Mimochodem, při rozbalení Intel procesoru souhlasíš s EULOU, podmínkami, které jsou k dispozici i online, to jsi nevěděl? Výzva zní, nerozbaluj, dokud se s nimi nesouhlasíš.

          • Co nebylo deklarováno, nemusí být garantováno… to právě tak není. Jak už jsem uvedl ony §§ výš, „Nejsou-li jakost a provedení ujednány, plní prodávající v jakosti a provedení vhodných pro účel patrný ze smlouvy; jinak pro účel obvyklý.“
            To znamená, že pokud jsem si koupil i7 7700K, očekávám od něj nějaký výkon – kdyby mi stačil nižší výkon, koupil bych si třeba i5. Pokud ale najednou výkon neodpovídá tomuto účelu, půjde o vadu výrobku, tedy vadu plnění. Je to trochu gumové, to uznávám, ale jestli by to prošlo nebo neprošlo je spíš otázkou uvážení soudu, rozhodně nelze ze znění OZ něco takového vyloučit.

            V praxi je nemožné deklarovat v kupní smlouvě funkci všeho – to by třeba u auta znamenalo možná desítky tisíc deklarací o tom, že bude fungovat každý šroubek. Proto zákon hovoří o obvyklém účelu.

            V právních úpravách zvykového práva (USA, UK) může být ochrana ještě významnější – viz např. tyto zprávy o tom, jak uživatelé žalují Samsung za kauzu baterií v Note 7 – http://www.independent.co.uk/news/business/news/samsung-galaxy-note-7-explodes-recall-customers-sue-over-exploding-handset-south-korea-a7377451.html
            Dost pochybuji, že v takovém případě Samsung deklaroval funkčnost baterie, tj. že nevybuchne. To se předpokládá automaticky.

            V právu vždycky platí zásada přiměřenosti – pokud by chyba procesorů znamenala snížení výkonu o 1 %, asi by Intel soudní spor ustál. Pokud ale budou propady o desítky %, jak se to jeví u serverových nasazení, můžou mít dost velký problém. I s ohledem na to, že to není industry-wide, tj. výkon neklesne všem, ale jen jim (což značí, že chyba je na jejich straně).

            EULA po pravdě nevím, procesory v poslední době samostatně moc nekupuju. Otázkou je taky právní závaznost takového povídání v podmínkách ČR. Součástí kupní smlouvy to není, muselo by jít o nějakou další smlouvu přímo s Intelem uzavíranou konkludentně.

  5. Je vhodná doba investovat do akcií AMD, včera měly pěknou jízdu o 7%, ale v průběhu roku to vypadá na stovky procent nahoru. Tedy, kdo dáte přednost větší jistotě před nejistými kryptoměnami, je AMD skvělou volbou. Minulý rok stagnovalo, tento rok ale začíná pro AMD velice dobře, uvidíme během následujících dní. Již moc času tedy na nejlepší nákup akcií asi nezbývá, po potvrzení domněnek může začít pořádné rally. Takže co nejdříve běžte do FIO a zažádejte o obchodní účet, k tomu kdyžtak EasyChange pro lepší kurz. GL

    • U AMD to není nijak razatní skok a rozhodně to zas až takovou souvislost mít nebude, protože patch v systému zjevně postihne i AMD platformu stejně. Nicméně spíš zpráva, že velká hlava z Intelu prodala velké množství akcií bude hrát prim. Jo a zohledni, že za poslední 2 měsíce akcie AMD propadly o 40%, pak se nediv, že před či po kvartálních výsledcích zase o pár procent vylezou… proč se v poslední době AMD tak propadlo? Protože vlna kryptotěžení opadla a marketshare AMD není zdaleka takový, jak si investoři nebo stakeholdeři obecně malovali, ale těsně po uvedení Ryzenu to teda začalo růst řádně o tom žádná.

    • Mimochodem, akcie se nekupují když jdou na horu, to už je často pozdě. Kupují se, když letí dolů. Při růstu nahorů můžeš nakoupit pozdě a příjde korekce a seš v jeteli. Spíš počkat kam až padne Intel a koupit ten, to bude mlska. Jinak teda z dlouhodobého hlediska bude podle mě jak AMD tak NVIDIA zajímavá investice. U NVDIDIA to za poslední 3 měsíce dělá tak 50 dolarů na akcii moměntálně, což je v procentech docela dost – tak já zisk počítám, solidní vejvar. Kdežto pokud jsi před 3mi měsíci při růstu koupil AMD za 14 dolarů, tak sis uhnal pěknej infarkt pád až pod 10 dolarů, protože se bublina kolem kryptotěžení trochu splaskla (těch pár nadšenců přestalo ADM karty na těžění kupovat) a zároveň Ryzen nedopadl tak, jak si investoři představovali. Marketshare pro AMD okolo 13% co jsem viděl poslední čísla sice není úplně špatné, na druhou stranu nemá AMD výrobní kapacity, který má Intel a to by mě zajímalo co by s tím jako AMD chtělo dělat i kdyby papírově Intel porazili ^^ (bazinga, Intelu stačí přeznačit 5 let starej Xeon udělat z toho i9 a máš odvetu na světě, žejo). Ale jo, pokud opravdu chceš investovat dlouhodobě v řádu několika let, tak vidím AMD někde kolem 40 v horizontu několika let, teda věřím jim. NVIDIA však za tu dobu zjevně udělá větší zisk.

    • Tak a máme 10%+: https://finance.google.com/finance?q=AMD

      Jak jsem psal výše, vidím to letos na stovky procent nahoru, tohle je pouhý začátek, takže uděláte dobře, když co nejdříve zainvestujete též. Srovnejte si tržní kapitalizaci firem (v Google Finance položka Mkt cap), tedy množství akcií vynásobené jejich cenou:
      Intel: $204B
      NVIDIA: $128B
      AMD: $11B

      Vidíte, s těmi stovkami procent nahoru nijak nepřeháním. Sám vidím akcie AMD na $30-50 v průběhu roku.

      • V průběhu roku určitě ne, to by museli růst výrazně růst prodeje a zisky, mnohem výrazněji, než je realistické, nebo se stát nevím jaký humbuk. Počítal bych plus minus s těmi úrovněmi, co byly maximem letos (15,50 – 16), a to ještě kdoví jestli.
        Když bude přetrvávat skepse a víra, že Intel a Nvidia jsou větší, tudíž AMD nemá dlouhodobě šanci, tak to může zůstat na těch 10 nebo dokonce klesnout…

  6. Tak je to tady, je to fixní a pokles je 65%, toto je oficiální stanovisko výzkumného úřadu BESA pro ověřování této záležitosti. Certifikace bude doložena ihned po dokončení dalších drobných testů.

  7. Další novinka, Alza má momentálně v nabídce, zatím zboží na cestě, dvě továrny Intelu, je to tedy pouze pro VIP zákazníky, uvidíme, nabídka se určitě rozšíří na další vlastnictví Intelu, toto už Intel nezastaví, peklo zamrzlo, brána je pro AMD a jejich špičkové technologie otevřena.

  8. Mimochodem jen jako kuriozita, úplně bych z toho nedělal haló a konspiraci, ale Brian Krzanich (šéf Intelu) koncem roku prodal v rychlém sledu půlku akcií Intelu, které držel, tu druhou půlku musí jako CEO držet povinně (250K).

    Je možné, že v té době už o tomhle průšvihu věděl (v listopadu už to pravděpodobně bylo interně známo a běžely práce na tomhle workaroundu, pod NDA). Ovšem taky je třeba říct, že v té chvíli byly akcie Intelu docela hodně nad tím, kde byly většinu roku, takže prodej je úplně pochopitelný i z normálních příčin, byť o nevypadá úplně dobře. Takže jak říkám, nedělal bych z toho skandál, ale je to zajímavá věc.

    • Není to úplně jak píšeš, to že je prodal je běžná praxe. Tidle hlavni je dostávají poměrně často a prakticky vždy je obratem prodávají, protože je dostanou s jistou výhodností, proč se jim oplatí akcie prodat a investovat do něčeho výdělečnějšího. Když se zamyslíš a podíváš se na čísla, tak Intel zrovna není trhač asfaltu v růstu ceny akcií a mnohdy je investice do jiných akcií nebo šikovného startupu výhodnější. Z v česku působících zahraničních firem často i zaměstnanci dostávají akcie, které okamžitě nebo později prodají, aby bylo na nový dům nebo auto.

    • Kdybych já měl akcie intelu, tak je prodám už dávno – tolik věcí už bylo rázu „tak tohle už je prostě musí bolet“, jenže pokaždé to nějak ustáli.
      Ale pokud se ta zpráva ukáže pravdivou, bude intel v hodně prekérní situaci. (podle SA) Při poslední generaci xeonů si rapidně zvedli ceny, což hnulo žlučí nejednomu výrobci serverů. V tuhle chvíli by měly být validace pro servery se Zenem hotové a do toho přijde zásah do výkonu intelů… To budou ztráty jak prase, včetně nehorázně štědrých pobídek, aby se jejich sklady vyprázdnily. Jediné, co intel udrží nad vodou, bude omezená kapacita GloFo.:)

      A teď druhá věc: pokud se znatelný zásah do výkonu bude týkat i Atomů, no tak to fakt potěš koště. Ty tablety a 2v1 něco takového opravdu ucítí.

    • Jo, oopravdu bych z toho konspiraci nedelal.

      http://www.tomshardware.com/news/intel-bug-performance-loss-windows,36208.html

      So Much FUD
      Intel CEO Brian Krzanich also recently sold $11 million in stock, which some have proclaimed is a sign that he’s unloading his shares before a pending disaster. However, Krzanich sold the stock under a 10b-51 plan, which is a pre-planned sale of stocks intended to prevent insider trading. The nature of Krzanich’s transactions makes it unlikely that the trades are a precursor of a major monetary loss for the company.

        • Jestli jsem to pochopil spravne, tak aplikacni vrstvy se patch nedotkne (pokud bude oprava bez funkcni chyby). Takze u clusterovych reseni asi budou aktualizovat jeden node po druhem (tj. maximalne kratkodobe ponizeni vykonu/redundace).

          • To zalezi system od systemu. Pokud to ma na priklad plne funkcni „Fail over“, tak muzou updatnout Mastera, zatimco Secundurni pobezi. A pak to prohodi nazpatek. Ne kazdy system ale takto funguje. Nektere priprietarni DB napriklad nemaji Fail over, takze to musi fyzicky zastavit. S tim se bude vazat i zastaveni servisnich sluzeb jnych serveru, ktere k tomu pristupuji, atd atd. Takze je to inividualni podle architektury reseni a bude to pro nektere problem,

    • Teda to je slušnej spin, na to že to děláte ve volným čase 🙂
      1. To je efekt té opravy, která ale u Epycu není potřeba, kdežto u Intelu jo. Patch už je commitlej v gitu, takže nulový propad u AMD na Linuxu je potvrzen.
      2. Těch 50% (to máte z toho jednoho tweetu, počítám) je u dd nebo syscalu samotného, zatímco ten skoro váš nulový propad u celkového měření desktopových programů (viz co jsem říkal o tom „rozředění“)… Tohle je srovnávání ananasu s pěnou na holení.

      Teda jestli je to humorný troll tak to se omlouvám za kažení, ale v těchhle debatách to holt někdo vždycky vezme vážně tak jsem měl potřebu se vyjádřit…

  9. Profesionálně sepsané, co k tomu říct, jak říkám bublina rychle splaskla, no ještě se uvidí jak to spíš zamává s Ryzeny, ale Intel je absolutně v klidu bez ztráty jediného bodu. Pouze chyby měření.

  10. P. Olšane, ale vy jste taky nahodil udičku )) věděl jste co přijde ze strany červeného táboru a obráceně ) ale P. DDw S… jste pěkně namazal, jen co je pravda)) to se musela v Plzni třást celá garáž když to tady četl.

  11. „To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time.“

    https://www.cnbc.com/amp/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html?__twitter_impression=true

  12. Tak už mi došlo jádro 4.14.11. Páně Olšanovým příkazem ověřeno, že Kernel/User page table isolation: enabled. PC Haswell nerefreš je kancelářské (+virtualbox) s klasickým HDD a první dojem je, že se žádná tragédie v provozním zatížení nekoná. Ba, snad podle budíkového měření se systém zavede o nějako vteřinku rychleji. HDD v benchmarku také je na hranici chyby měření. Možná na SSD to bude poznat v provozu.

  13. Tady je detailnější popis situace od Googlu
    https://googleprojectzero.blogspot.cz/2018/01/reading-privileged-memory-with-side.html

    Chyba oznámena Intelu, AMD a ARM už 1. června 2017.

    Varianta 1: bounds check bypass (CVE-2017-5753) – Spectre
    – Je možné číst data v rámci jednoho procesu – postiženy Intel Haswell, AMD Piledriver a Excavator a ARM A57. Nejde ale o závažný problém, protože nejsou překračována žádná privilegia (jediný proces).
    – Na Intel Haswell je dále možné číst v rámci uživatelských privilegií paměť kernelu v rozsahu 4 GiB. Rychlost 2000 bytů / sekundu. S určitým (nedefaultním) nastavením toto možné i na AMD Excavator.

    Varianta 2: branch target injection (CVE-2017-5715) – Spectre
    – Na Intel Haswell je možné z virtualizovaného stroje číst paměť kernelu hosta rychlostí asi 1500 bytů / sekundu, s nutným časem pro inicializaci v řádu desítek minut.

    Varianta 3: rogue data cache load (CVE-2017-5754) – Meltdown
    – Na Intel Haswell je možné číst paměť kernelu z procesů s pouze uživatelským oprávněním. Podmínkou patrně je, že cílová oblast je přítomná v L1 data cache.

  14. Linus Toward si ulevil smerem k Intelu..pry maji priznat chybu a ne publikovat marketingove zvasty :))
    “ A *competent* CPU engineer would fix this by making sure speculation doesn’t happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.
    I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
    .. and that really means that all these mitigation patches should be written with „not all CPU’s are crap“ in mind.
    Or is Intel basically saying „we are committed to selling you shit forever and ever, and never fixing anything“?
    Because if that’s the case, maybe we should start looking towards the ARM64 people more.
    Please talk to management. Because I really see exactly two possibibilities: Intel never intends to fix anything OR these workarounds should have a way to disable them. Which of the two is it?
    Linus Torvalds“