Intel nejspíš čekají problémy – bezpečnostní chyba v procesorech?
autor: Pavel Boček , publikováno 4.1.2018

 Dle dostupných zpráv, které se začaly rojit na Nový rok, možná čeká společnost Intel jeden z nejhorších průšvihů v historii. Postiženy mají být ale i procesory dalších výrobců.

V posledních letech se nejedná o jediný větší aféru, můžeme připomenout TSX bug v roce 2014 (Haswell/Broadwell), potíže s procesory Atom řady C2000 a možná i jiných (který stále dopadá na uživatele síťových úložišť, miniserverů, síťových prvků apod.). Další je poslední měsíce rozmazávaná platforma IME (Intel Management Engine), což je věc, která se zatím příliš nikam nehla, přitom je to potenciálně otevřená díra do spousty zejména pracovních počítačů, jelikož v nich běží a zpravidla se ani nedá prokazatelně vypnout. Nynější problém ale svým rozsahem může být ještě o řád horší, protože je zneužitelný mnohem snáze a bez jakéhokoli fyzického přístupu k počítači (s IME byly zatím předvedeny pouze útoky s přístupem k zařízení).

Co se na nás řítí?

Pokud to krátce shrneme, před pár měsíci se objevily nové možnosti útoků přes virtuální paměť s cílem převzetí kontroly nad počítačem z uživatelského prostředí, a to dokonce i uživatelskými interpretovanými skripty (např. Javascript), nikoli pouze přímo spustitelnými programy (binárky). S ohledem na to, že skripty jsou dnešní weby naprosto přecpané a jejich potenciál si nyní uvědomují i provozovatelé botnetů např. pro těžbu kryptoměn (typu CryptoNight a podobných), snad každému je zřejmý potenciál tohoto průšvihu (zasloužilo by si to už i jiné označení).

Potenciálně je možné nejen propašovat do paměti binární kód a převzít kontrolu nad HW, ale i (jen) číst obsah vyhrazené paměti jádra systému a tak se dostat např. k HW/SW klíčům, heslům a vlastně takřka jakýmkoli datům v paměti. Poměrně záhy začaly v historii téměř nevídaným tempem vznikat téměř anonymní a nedokumentované opravy v samotném core linuxového kernelu, které nyní začínají být nasazované. Současně i Microsoft začal urychleně pracovat na aktualizacích pro jádro jejich operačních systémů, které mají přijít příští úterý. Z prvotních testů, které jsou nyní k dispozici, vyplývá, že řešení na úrovni operačního systému může mít za následek zpomalení někde mezi 0 a 75 % s tím, že nejvíce asi problém dopadne na velké providery cloudových a virtuálních služeb, kteří mohou čelit propadu výkonu mezi 5 a 30 %.

Podle vyjádření Toma Lendackyho z AMD se problém netýká procesorů společnosti Advanced Micro Devices. Intel nechtěl zveřejnit podrobnější informace, dokud nebude k dispozici řešení, v reakci na množící se články ale včera přišel s předběžným vyjádřením, ve kterém se ostře ohradil proti tomu, že by byly problémem stiženy pouze procesory Intel, ale má se týkat i mnoha dalších výrobců čipů a řady operačních systémů. Intel ve svém vyjádření nepopírá, že budou mít opravy za následek pokles výkonu, ale míra zpomalení má být závislá na typu zátěže a časem by se měla snížit. Domácí uživatelé počítačů by pak podle Intelu neměli pocítit významný dopad na výkon. 

Virtuální paměť, chráněný a uživatelský režim

Pro ty, kdo se – stejně jako já – v této oblasti nepohybují a tak o tom mají informace jen velice povrchní (nebo to už dávno zapomněli), se pojďme ve stručnosti podívat, o čem se bavíme. Programy v moderních operačních systémech nepracují přímo s fyzickou pamětí, ale pracují s mezivrstvou spravovanou operačním systémem, virtuální pamětí. Ta je u všech významnějších systémů rozdělená do segmentů (stránek). Operační systém přiděluje stránky, vede si stránkovací tabulku (aby věděl, co je kam přiřazeno) a následně teprve umisťuje data z virtuální do fyzické paměti (zpravidla operační paměť RAM, různé vyrovnávací paměti v procesorech, ale i stránky na pevném disku). Program dostane vyhrazenou jistou spojitou část a o přiřazení reálné fyzické paměti se pak stará operační systém, přičemž překlad zajišťuje k tomu určená jednotka uvnitř mikroprocesorů. Systém podle svého uvážení s fyzickým umístěním dat různě šachuje dle potřeby (umístění v RAM či na sekundární úložiště jako stránkování, také nazýváno swap). Je poměrně zásadní vlastností, že různé programy mají každý svou vlastní virtuální oblast a nesmí sahat, ba ani vidět do virtuálního prostoru těch ostatních. Všechny běžné programy běží v tzv. uživatelském režimu.

Intel nejspíš čekají problémy – bezpečnostní chyba v procesorech?

Operační systém, resp. jeho jádro, běží v úplně odlišném, privilegovaném režimu jádra. Má také svůj vlastní virtuální adresní prostor. Tam běží i mnoho ovladačů, z čehož právě tak často vyplývají problémy s nestabilitou (špatně napsaný ovladač, případně HW problém, může vést k tomu, že jeden proces, např. ovladač, zapíše něco někam, kam nemá, což pak vede k pádu jádra a tím celého systému). Režim jádra dává všemu v něm provozovaném mnohem bližší přístup k HW, moderní procesory mají přitom přímo implementované mechanismy pro oddělené spouštění instrukcí v režimu jádra a v uživatelském režimu. Kdykoli nějaká aplikace potřebuje někam přistoupit (číst, zapsat), dojde k tzv. přerušení, kernel vykoná pár cyklů, provede HW operaci a vrátí prostředky programu. Výrobci mikroprocesorů x86 (tedy Intel, AMD a VIA) samozřejmě jdou uživatelům naproti a implementují mnoho mechanismů, jak nejrůznější procesy zrychlit a namísto SW řešením to řešit na úrovni mikroprocesoru složitějšími instrukcemi (tedy obvykle rychleji, s využitím méně instrukčních cyklů) přesně v souladu se zaměřením architektury (CISC). S rozmachem virtualizace před zhruba dekádou právě došlo současně s uvedením nové architektury procesorů Core, Nehalem, k nasazení výrazně vylepšené podpory virtualizace, a to i právě v oblasti práce s virtuální pamětí. Mnoho těchto mechanismů zůstává aktuálních doteď.

(K)ASLR

V Linuxovém jádře se za poslední zhruba rok událo poměrně mnoho změn, které téměř zcela překopávají systém práce s pamětí. Jednou z nich je koncept ASRL, Address Space Layout Randomization (randomizace rozložení adresního prostoru). Mj. díky práci rakouské Graz University of Technology byly odhaleny způsoby, jak se dostat k informacím o fyzickém rozmístění dat v paměti u dřívějších verzí systémů, kde jádra typicky uchovávala části dat ve stále stejných oblastech. Ty se daly díky chybám v jaderných aplikacích jistými způsoby práce s pamětí odhalit, nepovoleně rozšířit adresní prostor aplikace (aplikací) v uživatelském režimu a z oblastí programů v chráněném režimu pak číst, nebo do nich i zapisovat. Byla tak implementována metoda randomizace, která chráněné aplikace laicky řečeno „rozháže“ při každém spuštění na jiné místo, aby tak byla podstatně ztížena jakákoli možnost škodlivého kód zjistit, kde má jádro svá citlivá data umístěna. Není to přímo řešení, ale fakticky učiní pravděpodobnost úspěchu útoku předchozím způsobem blízkým nule. Jaderný ASLR (kernel ASLR či KASLR) tak má za cíl rozházet data jádra a jejich umístění před programy v uživatelské oblasti bedlivě tajit. V tomto však SW výrazně spoléhá na to, že HW, tedy zejména mikroprocesor, zajistí důkladné oddělení instrukcí v režimu jádra a instrukcí v programovém režimu.

Intel nejspíš čekají problémy – bezpečnostní chyba v procesorech?

Záhy však byly teoreticky popsány způsoby, jak KASRL úplně obejít právě zacílením útoku na HW, tedy mikroprocesor. Mezi jinými zejména útokem na TLB (transaction lookaside buffer), což je malá interní cache právě v jednotce pro zpracování paměti v procesorech (typicky mezi každou úrovní paměti), kam si jednotka ukládá poslední pozice překladů virtuálních adres na fyzické, aby si ušetřila čas při dalším volání. Někdo si možná vybaví aféru kolem TLB chyby u procesorů AMD Phenom, při které ve specifických případech mohlo dojít k poškození dat přesouvaných mezi cache procesorů (data byla v několika cache současně a mohlo dojít k jejich změnám na jednom místě a následně ke kolizi). ASLR a KASLR přímé metody řetězením škodlivého kódu do fragmentů (např. s využitím return-oriented programming/ROP) v podstatě znemožňují, neboť náhodné využívání paměti již aplikacím znemožňuje se dostat k informacím o tom, co kde v paměti je. Dá se však k nim dostat přes „postranní kanály“, například právě snahou dostat se do TLB. Dále jsou indicie, že problémy s TSX u některých procesorů v roce 2014 mohly vést právě i k úniku takových dat. Konkrétní už dříve využívaný způsob spočíval v tom, že aplikace záměrně vyvolala chybu typu page fault (přístup do paměti, která není adresovaná pro tuto aplikaci) a měřila si čas zpracování této chyby. Pokud tam nějaká data byla, opakování trvalo kratší dobu a kód tak mohl postupně zjistit, že v dané oblasti skutečně „něco je“, a to dál zneužít. Instrukce TSX toto řešila mnohem rychleji uvnitř procesoru, bez operačního systému, kód se tak dozvěděl stejnou věc mnohem rychleji a spolehlivěji. To Intel vyřešil vydáním mikrokódu, který TSX zcela vypnul.

Další metody se zaměřily na využití chyb v predikčních funkcích procesorů, které jsou jedním ze způsobů, jak výrazně mezigeneračně zvyšovat výkon. (Princip je takový, že procesor analýzou kódu odhaduje, jaké instrukce mohou být potřeba příště, a sám je už předem nahrává do paměti.) Tak se dala zjistit nejen platnost programu nedostupné virtuální adresy, ale i její velikost. V Linuxu mohl útočník dokonce SW prefetchingem zjistit i přesnou fyzickou adresu pro něj nepřístupné části virtuálního adresního prostoru.

Podezření na problém

Zcela dle doporučení Intelu při vývoji moderních OS došlo k tomu, že pro zrychlení operací systémy alokují části jádra přímo do oblastí aplikací v uživatelském režimu. Když pak program zavolá jádro přerušením, tak je načtení modulu a vykonání operací jádra rychlejší. Zabránění přístupu k těmto sekcím je zařízeno nižšími právy uživatelské aplikace uloženými v tabulce v procesoru. K tomu se právě dá postupy popsanými výše za jistých okolností dostat, nebo to obejít a přístup umožnit i neprivilegované aplikaci. Jedním z řešení by bylo striktně oddělovat oblasti uživatelské a jaderné paměti, což si ale vyžaduje poměrně značné přepsání konceptu jádra a navíc to má zásadní vliv na výkon, kdy je nutné často zcela vyprazdňovat cache procesorů a data tak načítat stále z operační paměti. To jde přesně proti konceptu dnešních procesorů a systémů, kdy je snaha naopak zbytečně velká kvanta dat nepřesouvat sem a tam. Rakouský tým sice přišel s návrhem konceptu KAISER (Kernel Adress Isolation) kterak za pomoci zcela nového šedého adresního prostoru problém vyřešit za údajně téměř nezaznamenatelného propadu výkonu (viz materiál KAISR), otázkou ale je, jak se k tomu pak při implementaci postavit.

Intel nejspíš čekají problémy – bezpečnostní chyba v procesorech?

Dle dění v posledních pár dnech je ovšem zřejmé, že problém je asi výrazně závažnější, než si kdokoli myslel, neboť popisované změny byly v pouhých několika posledních měsících, možná týdnech, implementovány přímo do linuxového jádra, kde se nyní objevují. Co je asi ještě horší je fakt, že dokumentace zcela chybí a popisy v kódu jsou zmatené. To vše naznačuje, že problém je dost závažný, a tak je záměrně udržováno embargo. Očekává se, že podrobnosti budou odhaleny příští úterý s tím, jak vyjdou kritické aktualizace operačních systémů Windows. Systém MacOS od verze 10.3.2 již údajně záplatu obsahuje. Mezitím několik největších poskytovatelů cloudových služeb ohlásilo na 10. ledna výpadek služeb s tím, jak budou instalovat aktualizace od Microsoftu. Utajená aktualizace připravená k vydání je už údajně připravena i u managera Xen. Jakýchkoli poskytovatelů virtuálních služeb se totiž problém dotýká také velice citelně – jak již bylo naznačeno, možnost dostat se do chráněné oblasti paměti znamená, že se může škodlivý kód na virtuálním stroji dostat dokonce i k datům na ostatních VM na tom samém fyzickém stroji. U hypervisoru Xen už údajně dokonce docházelo koncem roku k opakovaným kolům útoků. Že je to hrozba reálná a bug existuje, dokládá i důkaz, který připravil během psaní tohoto článku doktorand na univerzitě Vrije v Amsterdamu.

Z vyjádření vývojáře AMD Toma Lendackyho o tom, že procesory AMD nejsou zasaženy, neboť podobné funkce vůbec nevyužívají, se dá dovodit, že problém by se mohl týkat právě prediktoru v procesorech Intel (a dalších). V rovině spekulací se hovoří o tom, že procesory mohou za určitých okolností vykonat instrukce bez toho, aby si ověřily jejich oprávnění, a tím tak zcela obejít dosavadní opatření ze strany OS k tomu, aby se škodlivý kód nedostal do chráněné oblasti. Teoreticky jde problém řešit třemi způsoby: na úrovni mikrokódu, na úrovni operačního systému, nebo přepnutím procesoru na in-order zpracování instrukcí (což nám výkon vrátí někam k architektuře Atom starší než Silvermont, vycházející z Intel P5 – původní procesory Pentium a Pentium MMX). Spekuluje se, že chyba je tak závažná, že na úrovni mikrokódu rozumně opravit nepůjde, ostatně by tak již Intel nejspíš učinil. In-order také nikdo nechce. Proto bude nejspíše řešena na úrovni OS. Ačkoli to, že časem na úrovni mikrokódu vyřešena bude, je stále ve hře, neboť je možné záplatu (nejen kvůli procesorům AMD) i v Linuxu parametrem vypnout, případně také vůbec neaktualizovat (i když aktualizovat BIOS serveru je snad ještě horší a nedělá to skoro nikdo, když i dnes to nezřídka znamená, že bude do serveru zanesen ještě další problém, který tam před tím nebyl).

Nynější situace je taková, že jako nebezpečné jsou u linuxových patchů označeny všechny procesory Intel, jak informuje server Phoronix. Minimálně momentálně s touto poměrně horkou jehlou šitou záplatou tak bude platit, i přes výše zmiňovanou studii o KAISR, poměrně výrazný výkonnostní propad, který dle počátečních testů v některých aplikacích je zmiňovaných 5–30 %, ve specifických případech ale i výrazně více. Můžeme zatím pouze spekulovat, zda to je tím, že se koncept KAISR neukázal být vhodný, nepodařilo se jej tímto způsobem implementovat (nebo to přijde později), anebo je problém v procesorech tak závažný, že ani KAISR nepomáhá. Podrobnosti se dozvíme pravděpodobně až příští týden. Je pravděpodobné, že některé novější procesory budou časem označeny jako bezpečné. Rovněž ty z posledních generací, které mají instrukci PCID (Process-Context Identifiers) by měly být propadem výkonu zasaženy výrazně méně.

Jak již tedy bylo řečeno, v AMD si nemohli přát lepší začátek roku. Stihli již připravit patch, který nové záplaty u procesorů AMD neaktivuje, těch pár enterprise uživatelů procesorů Bulldozer navíc nyní dostane rovněž pěkný dárek, když všechny konkurenční servery postihne rána, která jejich výkon srazí. I přes zprávy o chystané těžké konkurenci se Ryzeny prodávají jako na běžícím páse (v popisovaném nasazení – stejně jako Bulldozery ve srovnání s Core té doby – překonávají i nynější procesory Intel velice výrazně), EPYC nyní dostane obrovský boost. Kdo chce dobře investovat, měl by rychle uvažovat o nákupu akcií AMD. Jen za včerejšek již zaznamenaly nárůst o 9 %, a to se informace teprve pomalu dostávají na světlo, zatímco Intel se zatím nejníže propadl o 7 % (a pak částečně vyrostl zpět).

Zdroj: python sweetness, The Register



Tagy: intel  bug  výkon  patch  
 
Komentáře k článku
RSS
Pouze registrovaní uživatelé mohou přidat komentář!
4.1.2018 08:17:18   78.45.59.xxx 1210
Co přesně se stalo ještě nikdo neví. Pravděpodobně se jedná o problém na úrovni spekulativního čtení paměti a spekulativního vykonávání kódu. Konkrétně když aplikace volá funkcí jádra, tak aplikace se může dostat k informacím z jádra ještě před přepnutím režimu procesoru aplikace-jádro, protože v tu dobu již mohou být načteny pomocí spekulativního čtení.


TSX bug s tím nijak nesouvisí.
4.1.2018 08:35:14   90.176.73.xxx 2210
nikdo nic nevi? si delas srandu... na konkurencnim webu vysel clanek a rozbor uz vcera, intel vydal PR zpravu, usporadal konferecni hovor s investory, velke spolecnosti planuji na tento a pristi tyden odstavky svych systemu/sluzeb... prej nikdo nic nevi...
4.1.2018 08:41:51   78.45.59.xxx 613
Prdlačky, všechno jsou to spekulace a v kódu patche pro Linux jsou smazány komentáře. Dej link na pořádný zdroj.
4.1.2018 08:54:31   90.176.73.xxx 127
tady to mas ty prdlacko

https://www.pcworld.com/article/3245508/components-processors/intel-responds-to-the-cpu-kernel-bug.html

During a conference call Wednesday afternoon, Intel shed more light on the CPU kernel vulnerability, now being referred to as a “side channel analysis exploit.” Expect to see patches roll out to address the flaw over the next several weeks, Intel executives said. The performance impact of the patches is expected to be at frustrating levels—somewhere between 0 and 30 percent, though “average” PC users are expected to see little impact.
...

The flaw was first discovered by Google’s Project Zero security team, says Intel, which Google confirmed.

...

The companies had planned to make the disclosure next week when the patches became available.
4.1.2018 09:08:04   78.45.59.xxx 514
... máme zase prdlačky, tohle není pořádné vysvětlení.
4.1.2018 19:40:13   151.237.229.xxx 50
Chces poriadne vysvetlenie, tak tu mas. Ak pochpopis co i len polovicu, mas moje uznanie.

https://googleprojectzero.blogspot.cz/2018/01/reading-privileged-memory-with-side.html
4.1.2018 23:54:44   78.45.59.xxx 03
Pochopil jsem to celé, ale z jiného zdroje.
4.1.2018 08:58:16   90.176.73.xxx 34
Google also reported that its Chrome browser is affected, though there’s a two-step cure: first, make sure that your browser is updated up to version 63. Second, an optional feature called Site Isolation can be enabled to provide mitigation by isolating websites into separate address spaces.

....

“We’re aware of this industry-wide issue and have been working closely with chip manufacturers to develop and test mitigations to protect our customers,” a Microsoft spokesperson said in an email. “We are in the process of deploying mitigations to cloud services and have also released security updates to protect Windows customers against vulnerabilities affecting supported hardware chips from Intel, ARM, and AMD.”
4.1.2018 21:12:47   77.87.242.xxx 11
Eště že mám Operu a BD
4.1.2018 08:55:19   94.112.242.xxx 54
Zatím není jasné ani pořádně jak to bude dál. Nové revize HW? Postihlo to i ARM (podle určitých indicií ANO!!)? A hlavně není ani pořádně zdokumentován kód v Linuxovém kernelu který to opravuje. + Penalizaci výkonu u opravy...
4.1.2018 09:20:58   109.107.210.xxx 140
ARM (stejně jako AMD a Intel) je postiženo jinou (podobnou) vadou pojmenovanou "Spectre." V tomto případě je ale její zneužitelnost zatím pouze v teoretické úrovni.

Problém "Meltdown", proti kterému je aplikován KAISER patch, a který je reálně exploitovatelný, je pak vlastní pouze Intelovským CPU, která nejsou in-order (tj. vše s výjimkou starých Atomů)
4.1.2018 21:14:09   77.87.242.xxx 20
Dost možná opravdu vše od P6, tj. Pentia Pro a Pentia II (včetně) nahoru, Atom pak od Silvermont dále (taky už jsou to out-of-order).
4.1.2018 22:00:37   51.15.40.xxx 10
V kontextu tohoto vznikají otázky ohledně podpory a záměrů MS - dočkáme se i na WXp? nestane se podobná kauza záminkou k pobídce na upgrade W?
4.1.2018 22:33:13   77.87.242.xxx 10
Jasně no. Taky se uvidí, na čem všem se to dá reálně zneužít, pokud je to skutečně jen Nehalem a dál, tak to už je asi bezpředmětný - jdou na tom vůbec XPčka? IMHO na ty čipsety už nejsou ovladače. A kdo to na tom provozuje, že…

Ale zas pokud je to i problém starých CPU, tak PoS 2009 by měl update dostat
4.1.2018 22:38:10   176.10.99.xxx 22
Baví mě jak Krzaniche doslova protahují všemi kanály https://byznys.lidovky.cz/sef-intelu-krzanich-vedel-o-zavade-cipu-zbavoval-se-akcii-pej-/firmy-trhy.aspx?c=A180104_143752_firmy-trhy_sij Je to sice ta nejnižší struna škodolibosti, ale nemůžu se ubránit - mám radost, že to má takový impakt
5.1.2018 07:02:22   109.105.39.xxx 24
Že by byl někdo jako CEO Intelu až tak blbej, aby v praxi předvedl ukázkové zneužití neveřejných informací? Ale no tak...
5.1.2018 09:21:09   78.45.21.xxx 11
Tak jinak... kdyz by to byli Vase akcie a ocekaval by jste treba 5-10% pokles s tim, ze ocekavate ze se to zpatky jen tak nevyhrabe.
V jeho pripade se jedna o radove miliony dolaru.
Vy by jste to neudelal?
ps: a by to bylo zneuziti informaci, tak by jste mu musel dokazat umysl. Jak toto dokazete, opravdu nevim.

Takze no tak.. ;)
4.1.2018 21:11:52   77.87.242.xxx 30
Já ale taky nepsal, že to je TSX bug. TSX bug byl jedním ze způsobů, jak obejít zabezpečení metodikou KASLR, načež bylo navrženo využití KAISER. Co by se tady mohlo dít je něco novýho, co to dokáže obejít, možná i mnohem snáz zneužitelnýho, co by mohlo obcházet i KAISER.

Podle dalších informací to vypadá, že patch v Linuxu je zatím taková rychlovka, která prostě v základu u všech procesorů x86 přechází na hrubě oddělené prostory jádra a aplikací, což s sebou nese i mnohem častější vyprazdňování cache (flush). AMD na to reaguje vydáním hotfixu, kterej to vypíná při detekci procesoru AMD.

Co je SKUTEČNĚ problémem se zcela jistě zatím neví - nebo aspoň sem to nenašel včera - uvidíme až se vydaj dokumentace. Pak začnou vycházet skutečný záplaty, nebo aspoň jejich selektivní aplikace na skutečně zranitelný procesory.

Je pravda, že zmíněná záplata hrubě oddělující adresní prostory skutečně paušálně zvyšuje bezpečnost všude. Na druhé straně se ale tvrdí, v rozporu s PR zprávou Intelu, že ARM a AMD to nepotřebuje. ARM64 má navíc dva bity v registrech, který specifikují práva procesů a tak se nemůže nikdy stát, že to spustí něco uživatelskýho v privilegovaným (vyšším) režimu, protože to vždycky ví, co odkud pochází. U AMD vlastně možná podobně, protože snad nikdy nepustí nic z nižšího ringu do prostoru paměti vyššího ringu bez jasnýho přiřazení.
4.1.2018 08:55:14   80.188.118.xxx 2926
Se musím smát, že se tu někdo se mnou tady nedávno v diskuzi hádal, jak by si AMD nekoupil, protože nutně potřebuje ten SUROVÝ výkon Intelu. Tak tady ho má, jenom mu ho teď zkrouhnou :-)

Jsme zvědavý, kdy se jim podaří snížit tu šílenou degradaci výkonu a o kolik, zda se to vůbec někdy vrátí na původní stav.
4.1.2018 09:17:21   109.107.210.xxx 75
Není jak. Je to hodně podobné TLB bugu z Phenoma B2. Výkonová penalizace patchem je v tomto případě to nejmenší a v podstatě jediné rozumné řešení.
4.1.2018 09:32:47   185.211.190.xxx 82
Moc k smíchu to není, pokud totiž nebudu zlomyslný vůči nějaké značce, tak to poukazuje pouze na fakt, že takové "polovodičové struktury" jsou natolik složité, že i největší výrobci stále dokážou udělat velmi závažnou chybu (je to stejně vrtkavá technologie, jako před dvaceti léty).
..dnes je to Intel, zítra Nvidia, pozítří AMD a poškozené budou pokaždé miliony zákazníků.
4.1.2018 09:57:33   94.242.92.xxx 1827
Tak Ajne měl velmi čecháčkovskou reakci. Úplně zapomněl jak prasácky optimalizované Ryzen byly a mnohdy ještě jsou.

Teď mě tu asi zavalí palce dolů od všech majitelů Ryzenu, ale než se tak stane, je třeba si položit otázku. Jak velké bezpečnostní riziko hrozí běžnému uživateli/spotřebiteli? Jak velký propad výkonu lze u spotřebitelského HW čekat? Všem je jasné, že případné zneužití bezpečnostní díry bude mít spíš dopad na podniky, vládní organizace apod. Neumím si představit, že by počítač běžného uživatele byl tak lákavý, že by někdo ztrácel čas zneužitím CPU na takové úrovni, o které se může běžnému uživateli jen zdát.

Zároveň se ale už nikdo tak moc nepozastavuje nad zneužíváním strojového času běžných uživatelů, kteří ani mnohdy neví, že jejich stroj těží kryptoměnu pro někoho na druhé straně planety. Žijí ve své bublině nevědomosti, stahují vše čistě pro vlastní potřebu, takže nikomu neubližují a je jim to jedno. Pak přijde článek jako je tento, kdy ještě ani sám Intel pořádně neví co a jak bude řešit, ale oni už jsou rozhodnutí, další CPU bude AMD. Do toho přijdou odborníci z PC tuningu, kteří vždycky věděli, že je s Intelem něco špatně, všem to říkali a tak dále.

Situace by byla jiná, kdyby tady opravdu byl zaměstnanec Intelu z R&D a mohl se ke všemu vyjádřit. Což se ale nestane. Takže dokud nedojde na lámání chleba, je třeba být klidný s výroky.
4.1.2018 10:05:27   85.159.110.xxx 64
u neopatchovaneho systemu s Intelom?

https://mobile.twitter.com/misc0110/status/948706387491786752
nuda nie?
4.1.2018 10:24:43   94.242.92.xxx 319
Rozbalit komentářPříspěvek byl automaticky zabalen pro velké množství negativních hlasů.
4.1.2018 10:29:36   85.159.110.xxx 185
aha, uz vidim hackerov dnesnych dni behat po velkych firmach s 100K pocitacmi a pripajat zariadenia na nejaky usb sniffer
len otacas, hore si sa pytal, ake velke bezpecnostne riziko to je. ja vravim ze velke, a doplnam linkom, preco. A ty to bagatelizujes, lebo Intel svaty a jediny.
Ryzeny ako take neoptimalizovane boli len nevyuzivani lepsich ram. trvalo to 3 mesiace, kym sa to dalo dokopy. Ako to suvisi s bezpecnostnymi dierami Intel procesorov?
4.1.2018 10:38:20   192.42.116.xxx 710
Ryzeny mají taky problémy ve specifických úlohách, došlo i na výměny. Jejich pověst ale nemůže utrpět tolik, co Intelu.
4.1.2018 10:44:21   85.159.110.xxx 36
to som nezachytil, ale ok. vies nieco o tom viac?
4.1.2018 11:10:42   51.15.86.xxx 39
Rozbalit komentářPříspěvek byl automaticky zabalen pro velké množství negativních hlasů.
4.1.2018 11:35:08   93.115.95.xxx 33
Z hlediska nutnosti diverzity asi není kritičtější oblasti, než je bezpečnost. S poptávkou, potažmo nabídkou výrobců, by takovéto zprávy konečně mohly zacloumat.
4.1.2018 10:51:36   94.242.92.xxx 41
No pozor, ta finta s USB spočívala v tom, že si ''zneužil'' ID chip uvnitř USB zařízení (klávesnice, myš, gamepad...). Takovou věc pak stačilo jen připojit, u Windows si systém hledá ovladače sám a bylo vymalováno.

Jinak, krádeže informací z velkých IT firem se dělají vcelku jednodušším způsobem. To máš takhle zaměstnance s vyšším oprávněním uvnitř firmy, který má firemní notebook. No, a co se nestane, notebook se ''ztratí''.
4.1.2018 11:09:45   85.159.110.xxx 31
niesom si isty, ci minimalne neexistuje rozdiel medzi ID usb citacky a ID mysky. pretoze existuju programy, kde vies blokovat usb zariadenia(maju to uz aj nove antiviry)
mozno sa da napalit na nejake zariadenie jeho ine ID, ale potom OS ma problem pridelit mu spravny driver nie?
4.1.2018 13:04:45   194.1.226.xxx 00
Ono tam pri tych USB islo o inu vec - v podstate, ten USB dongle moze emulovat beznu klavesnicu, ktora len pusti dajaku sekvenciu klaves, napriklad Win+R, cmd.exe, enter, pripoj sa na dajaku stranku, atd... proste cely ten kod sa vykona na systeme, bez toho ze by si uzivatel uvedomil ze sa nieco stalo a system uz moze byt kompromitovany.
4.1.2018 12:52:23   85.132.203.xxx 05
Já jsem brutálně zabezpečnou firmu s nějakým linuxem v linuxu běžícím systémem na sereru obechcal blbým teamviewrem...
4.1.2018 10:36:20   80.188.118.xxx 276
Když nechápeš psaný text, tak neodpovídej. Nepíšu, že je směšná chyba (mám i NTB + pracovní PC na Intelu, takže to poznám taky), ale to, jak se tu se mnou v nějaké diskuzi někdo do krve hádal, že AMD je naprd, protože NUTNĚ potřebuje ten surový jádrový výkon Intelu, tak si raději koupí i7, nechá si udělat delid (a přijde o záruku), než se trápit s tím o pár % nižším výkonem AMD. No a teď to dostalo korunu tím, že má předražený CPU, bez záruky, a výkon v pr....takže asi tak.
4.1.2018 21:28:33   77.87.242.xxx 60
Zneužívání počítačů jako celku tu už je velice dlouho, botnetový sítě vám něco říkaj? Obvykle na DDoS, až v poslední době i těžební viry. Obvykle se do systému leze přes bezpečností díry v SW, protože se i spolíhá, že HW bezpečnej je.

Pokud HW v tak ohromným množství bezpečnej není, tak je to obrovskej průser, a zneužitelnost je ohromná. Od čtení věcí, kam to nemá mít přístup (jako že systémových věcí) po samozřejmě získání výlučnýho přístupu k HW, spuštěním klidně strojovýho kódu, a následné totální obejití OS a převzetí kontroly nad počítačem. Demonstrovány byly tyhle útoky i přes JS, jak jsem psal. A ten je úplně všude. To vám nepřijde jako problém?

Jinak naopak u běžných firem a úřadů co mají vlastní stroje, kde uživatel nic nespouští, to problém ani není. Problém to je u hostingů a providerů, kteří pronajímají v podstatě výpočetní výkon, kde si pak může útočník resp. škodlivej kód něco pustit v jedné VM a získat přístup na všechno.
4.1.2018 21:15:36   77.87.242.xxx 80
U Intelu je ale těch průserů poslední dobou hodně, tak je možná dobrý si to uvědomit a neustále fanaticky nepropagovat jak je Intel ten úpa zupa nejlepčejší ve všem. Což dělá nejen tady docela hodně lidí.
4.1.2018 21:46:25   51.15.40.xxx 20
V posledním roce se dá vysledovat zbrklost, Intel je evidetně pod tlakem a rozhodně nemá neotřesitelnou pozici - to je to, co si tady spousta lidí maluje.
4.1.2018 21:21:11   77.87.242.xxx 21
Pokud vím, tak v Linuxu se dal TLB bug řešit fixem, kterej postihoval výkon velice málo.

Jenom u oken se to řešilo často prostě fixem přes BIOS že když záznam není v TLB, tak se řadič nesměl podívat do cache, ale přímo do RAM. Ale stačilo to taky vůbec neřešit pže pravděpodobnost, že se to stane na desktopu při běžným použití, byla téměř nulová.
4.1.2018 09:55:05   78.45.21.xxx 61
Zajimave pocteni, diky
4.1.2018 19:39:05   151.237.229.xxx 02
Praveze autor tomu tazko nerozumie, pletie tu veci okolo TLB a ASLR, ktore s tym absolutne nesuvisia.
4.1.2018 21:34:07   77.87.242.xxx 30
Zmiňuju v kontextu co to vůbec TLB je, že obcházení (K)ASLR přes problémy TLB bylo jednou z metod, jak se stále do vyššího ringu dostat, a dále jsou to spekulace o tom, v čem by problém mohl být. Jestli je to další bug v TLB, bug danej predikcí nebo něco úplně jinýho. Přečetl sem si včera dost věcí a mimo spekulací nic moc kloudnýho.

Pokud o tom víte víc, tak se můžete podělit…stejně jako dál blábolit, jistě
4.1.2018 10:08:47   45.79.208.xxx 20
Já už se znepokojeně rozhlížel, kde se nám ten B ztratil. Je to problém zejména enterprise, odchod Diane Bryant nutí k zamyšlení. Hlavně co takový otřes důvěry udělá s postojem výrobců k AMD.
4.1.2018 10:51:27   185.59.186.xxx 163
No, bez ohľadu na to ktoré konkrétne generácie to teda postihne, pri počtoch predaných Intel CPU v akomkoľvek segmente to vyzerá tak že kauza z GTX970kou bude oproti tomu len drobnou, vlastne lokálnou nepríjemnosťou

Tak uvidíme, čo to spraví z reálnym výkonom, obzvlášť herným keďže posledné roky vlastne od Sandy i5/i7 sú Intely parádne herné CPU...

Každopádne, asi poriadny prúser
4.1.2018 12:23:31   212.27.208.xxx 41
https://www.youtube.com/watch?v=_qZksorJAuY

pro hry je to spis pozitivni, ale provozovatele datacenter asi strihaji pulkama osmicku drat....
4.1.2018 14:32:48   165.225.72.xxx 212
Rozbalit komentářPříspěvek byl automaticky zabalen pro velké množství negativních hlasů.
4.1.2018 15:25:38   213.226.209.xxx 111
- tak Intel brutálně v rámci "dmg control" mlží a neumí se k tomu postavit čelem (horší je to v tom že už o tom vědí pekelně dlouho takže to byla jejich prvoplánová strategie a hádám že teprve dle reakcí zákázníků změní přístup ..jestli vůbec)

- propady jsou meřitelné i v desítkách procent takže jestli nepřijde nějaká zázračná revize současných oprav v OS či IME tak je věc docela jistá teď už jen změřit kde jsou největší ztráty a kde naopak minimální (v herní oblasti jsou rozdíly max pár % takže naprosto zanedbatelné v rámci chyby měření)

ohledně 970 ten dopad byl .. před nahozením opravy kdy se odstavila pomalejší paměť na vedlejší kolej se to projevovalo a i po aplikaci opravy při potřebě více jak 3,5GB VRAM se to projevilo ... jen díky tomu že to byla mírně ořezaná GTX 980 s dostatečnou rezervou výkonu to uživatel skoro nepoznal(spíš neměl s čím porovnat aby poznal rozdíl) navíc málo titulů si sáhlo na víc jak 3,5 GB s takovým nastavením aby 970 podávala slušné fps nic to nemění na tom že NV lže o svém produktu
4.1.2018 21:30:57   77.87.242.xxx 30
Údajně se koncem roku začaly objevovat cykly dost těžkejch útoků na hypervizor Xen a má to souviset právě tady s tím, takže to dost možná už někdo skutečně i stihl zneužít před tím, že se to začlo narychlo záplatovat.
4.1.2018 11:08:44   84.16.50.xxx 181
Intel možná použil chybku v CPU na serverech tyden.cz a změnil název článku z "Intel možná čeká nejhorší průšvih v dějinách" na Intel nejspíš čekají problémy"
4.1.2018 14:48:13   213.226.209.xxx 312
tak DD reakci máme a teď se strašně těším na Obrův článek určitě nám to všem vyvrátí že to tak není a problém se ve skutečnosti týká hlavně AMD
4.1.2018 14:27:30   86.49.116.xxx 23
hahahahaha
4.1.2018 15:59:20   83.208.208.xxx 30
Asi průser co?
4.1.2018 18:26:34   46.16.121.xxx 24
U hovadin složených z 0 a 1 je bát se o soukromí zbytečná paranoia...každý schopnější "hacker"(=nějak hendikepovaný jedinec plný mindráků a předsudků nudící se někde sám a bez peněz) vždy vymyslí to, co někdo nedomyslí. Kolik z Vás je na Facebooku/Twitru, má ho nainstalovaný na mobile/PC/notebooku/tabletu? Takže čučet teď na zadní vrátka, které někdo objevil... Už náš slavný Bill(G) u svého prvního ofiko programu na škole měl smiřovačku aby věděl jaké kočky kam nastupují, a to zatím neměl z toho žádný profit... Seru na to a výkon bude stejný... Kdo je připojen, ten je znám každému kdo velmi chce.
4.1.2018 23:50:30   78.45.59.xxx 00
Tak máme konečné vysvětlení, principiálně platí pro meltdown i spectre:
1) Nejedná se o "pravý" bug, aplikace nemůže běžným postupem číst data na která nemá nárok.
2) Data unikají prostřednictvím postranního kanálu pomocí informace cache-hit / cache-miss.
3) Bug spočívá v objevení postupu, jak procesor donutit pokusit se načíst paměť na kterou aplikace nemá přímo povolení, pomocí spekulativního čtení a následně výsledek čtení odeslat postranním kanálem.
4) Postranní kanál spočívá v sadě cache lines, kde index cache line s cache-hit představuje výsledek operace, ostatní cache line mají cache-miss.
5.1.2018 06:45:48   77.87.242.xxx 20
Včera už jsem něco v tomhle smyslu taky zahlíd…přičemž se psalo, že to skutečně využívá současně i chyby v prediktoru, kterej si nekontroluje oprávnění.

AMD se mimochodem podle jejich vyjádření netýká ani jeden ze tří způsobů, jak se k tomu dostat, kvůli odlišné implementaci.
5.1.2018 07:36:20   78.45.59.xxx 01
Nejedná se přímo o chybu, aplikace se k výsledku nedostane, výsledek operace na kterou aplikace nemá právo se zahodí. Únik spočívá v detekci, zda CPU taková data načetl do cache.

AMD se netýká pouze meltdown.
Spectre se týká Intelu, AMD i ARMu a patrně všech dalších se spekulativním vykonáváním kódu.
5.1.2018 08:07:03   88.208.95.xxx 21
Narozdíl od Meltdown je Spectre čistě teoretická záležitost. Meltdown je prakticky a prokazatelně napadnutelná díra. A ano, jedná se přímo o chybu. Je to záležitost poskytující možnost napadení (pojem "vulnerability" vám předpokládám něco říká), o které Intel věděl ještě před vydáním Coffee Lake, který stejně vydal (hned po tom, co CEO prodal své akcie).
5.1.2018 08:14:16   78.45.59.xxx 03
Plácání si nechej a přečti si výše uvedené moje vysvětlení. Spectre jsem si osobně vyzkoušel a funguje třeba i na Sandy Bridge
5.1.2018 08:32:17   78.45.21.xxx 11
Tak to jsi se taky urcite docetl. ze Spectre jsou 2 typy, pricemz u toho jednoho se to bude resit na urovni aplikacni vrstvy. To je pravdepodobne te, ktery jsi si vyzkousel.
Meltdown dira v Intelu je. Jestli je to opravdu chyba v jejich implementaci nebo chyba navrhu jejich implementace, je nepodstatne.
5.1.2018 08:35:50   78.45.21.xxx 10
A tenhle problem si Intel urcite neda moc za ramecek. Udajne se o nem vi od cervna, a od te doby Intel vydal jak Skylake-X, tak Kafe.. tudiz CPU o kterych vedel ze jsou vadna a sly na trh.
Ve firemnim sektoru si myslim bude obcas nekdo pekne na*raty ;)
5.1.2018 09:07:43   88.208.95.xxx 20
Znova, pokud vím, je zkouška Spectre pořád jen teoretická. Až někdo ukáže, jak tímto kanálem vysává hesla, tak se můžeme bavit, jak "funguje".

A samozřejmě, že to teoreticky funguje na Sandy Bridge, na těch jsou všechny varianty Spectre a navíc mnohem pálivější Meltdown, ne?

Plácání je leda tak vaše omlouvání Intelu relativizací slova "pravý" nebo "bug" v bodě 1) a míchání S Spectre s nesouvisejícím popisem Meltdown v bodě 3), jak se ostatně může každý přesvědčit na https://meltdownattack.com/ . Takže děkuji za plácavé vysvětlení, ale ne děkuji
5.1.2018 09:38:43   78.45.59.xxx 14
No tak to víte špatně a bude to tím, že se ani neobtěžujete číst informace které sám linkujete, na konci PDF Spectre Paper je přímo ukázka v C
5.1.2018 11:02:04   88.208.95.xxx 00
Spíš vy se neobtěžujete číst, co píšu. Konkrétně druhá mého předešlého příspěvku věta vám nějak vypadla.

To je asi tak na úrovni napsání "Hello world!" a tvrzení "mám webovou stránku". Prakticky využít Spectre (zvlášť tu variantu, která částečně platí i na procesory AMD) je v reálném světě trochu jiné kafe.
5.1.2018 09:00:36   77.87.242.xxx 22
Jo, právě za použití technik měření délky vykonání instrukce, tak to pak pozná, jestli se to trefilo, nebo ne a může hádat znova. Proto sem o tom psal.

AMD se to údajně netýká proto, že u nich je délka cyklu stejná nezávisle na tom, jestli data byla správná, nebo ne. Myslim že todle je možná důvod, proč měl Intel o něco vyšší IPC (sem tam se něco vykonávalo rychlej)…a teď o to přijdou
5.1.2018 09:43:25   78.45.59.xxx 10
Není to délka cyklu, u AMD meltdown nefunguje jednoduše proto, že neprovádějí spekulativní vykonávání kódu přes hranici přepnutí aplikace-jádro.
5.1.2018 07:09:57   194.48.241.xxx 42
Pročpak tuto novinku nenapsal Zdenda?
5.1.2018 08:36:37   78.45.21.xxx 52
Zdenda uz pripravuje clanek o tom, jak je to vsechno jeden velky humbuk a zadna chyba nikdy nebyla )
5.1.2018 10:34:30   85.159.110.xxx 13
nie nie, podla mna upravuje testy Titana Volty
5.1.2018 10:47:09   78.45.21.xxx 13
Mozna vyda 'combo' clanek o obojim )
5.1.2018 09:37:40   185.137.125.xxx 32
Prosim redakci at se k teto tematice vyjadri nezaujaty redaktor Zdenek Obermeier. Nejaky PR clanek od intelu by siknul. A taky reakce na to proc sef intelu prodal velkou cast svych akcii. Viz https://zpravy.e15.cz/byznys/technologie-a-media/sef-intelu-prodal-akcie-driv-nez-firma-oznamila-problemy-1341819 https://www.novinky.cz/internet-a-pc/bezpecnost/459474-sef-intelu-se-zbavil-akcii-firmy-za-stovky-milionu-tesne-pred-skandalem.html https://www.letemsvetemapplem.eu/2018/01/05/sef-intelu-prodal-vetsinu-svych-akcii-jen-par-dni-pred-tim-nez-vyplul-na-verejnost-skandal-s-vadnymi-pr... atd...
5.1.2018 14:02:36   212.27.208.xxx 00
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.

Redakce si vyhrazuje právo odstranit neslušné a nevhodné příspěvky. Případné vyhrady na diskuze(zavináč)pctuning.cz

137 čtenářů navrhlo autorovi prémii: 67.7Kč Prémie tohoto článku jsou již uzavřené, děkujeme za váš zájem.
Tento web používá k poskytování služeb soubory cookie.