On je to spíš seriál:
https://answers.microsoft.com/en-us/windows/forum/windows_7-update/stop-0x000000c4-after-installing-kb4056894-2018-01/f09a8be3-5313-40bb-9cef-727fcdd4cd56?auth=1
https://www.reddit.com/r/sysadmin/comments/7ode4s/problems_with_windows_7_quality_rollup_kb4056894/?sort=new
https://www.svethardware.cz/zaplaty-pro-meltdown-a-spectre-jsou-vysoce-problematicke-na-starsich-cpu-od-amd/45840
http://pc-help.cnews.cz/viewtopic.php?f=118&t=195666
mam tomu chapat tak, ze musim vediet co robi kod victim aplikacie, na zaklade toho si spravit villain aplikaciu s podobnym kodom a tam zjednodusene ked zapis "a" do pola prebehne rychlejsie ako zapis "b" do pola tak viem ze prve pismeno pola s heslom je "a" lebo uz je niekde tato operacia nakesovana?
Ono je to trošku jinak. Ve "svojí" nechráněné paměti si alokuješ pole o 2 prvcích na rozhraní 2 cache line. V dalším kroku zajistíš, že ani jeden prvek nebude v cache (flushneš). Následně máš spekulativní kód ve kterým uděláš následující: čteš bit z chráněné paměti (což by vyvolalo výjimku kdyby se vykonalo nespekulativně) a pokud je bit nula, přečteš (třeba do nějaké pomocné proměnné) nultý prvek pole, pokud jednička, přečteš první prvek pole. Tím se ti ten daný prvek pole dostane do cache. Pak v "normální" části kódu přečteš oba prvky a měříš čas jak dlouho to trvalo. Ten prvek který se přečetl rychleji byl v cache a tudíž je jasné, jaký bit byl v chráněné paměti.
AFAIK je to trochu naopak, protože v "normální" části kódu se chráněná data číst nedají a vyletí rovnou výjimka. Na začátku mám v cache vlastní data, ke kterým mám přístup, ale jsou na adresách, které se mapují na stejnou cacheline jako ta chráněná. Přístup k chráněné paměti některá moje data z cache vyhodí. Ta, která to byla, se pak musí načíst z RAM a tudíž pomaleji.
Ani ASM ten přístup nemá. Z cache se v tom útoku nevytahují data, ale informace o přítomnosti nebo nepřítomnosti stránky.
Meltdown spočívá v tom, že procesor do cache vloží stránku i na základě hodnoty, ke které nemáte přístup. Zjednodušená verze:
- máte pole_stranek[256]
- vyvoláte neočekávaný skok, takže prediktor nechá spekulativně vyhodnotit následující kód
- přečtete pole_stranek[*0x12345678] - spekulativně vykonané
Ta adresa je pro Vás normálně nepřístupná, Hodnota z dané adresy se použije jako index do pole, a ten prvek z toho pole skončí v cache.
Pak přečtete všechny prvky z pole_stranek a měříte čas každého přístupu. Stránky, které v cache nebyly se musí načíst a tudíž přístup trvá déle (400 taktů). Ta stránka, která tam byla je přístupná "hned" (200 taktů). No a index té "rychlé" stránky je hodnota, kterou jste neměl vědět. Opakujte pro adresy z celé paměti.
Stránka je běžně používaný pojem v oblasti virtuální paměti a dokonce přímo použitá pro popis Meltdown v oficiálním článku [1][2].
Bude stačit jednoduché vysvětlení? Stránka je nejmenší možná velikost paměti pro účely mapování mezi fyzickými a virtuálními adresami. V meltdown paperu stránka = 4096B
[1] https://en.wikipedia.org/wiki/Page_(computer_memory)
[2] https://meltdownattack.com/meltdown.pdf
ok, ale cache v procesoru nebo virtuální pamět(swap) není to samé. Virtuální pamět ovládá zcela OS a dá se k ním programově snadno přistoupit a číst ale číst cache v procerosu či k ní přistupovat to už je něco zcela jiného..
Píšeš to fakt nějak zmateně.
B bývá byte což v tém případě pokud je stránka 4096B = 4 MB, tak to pole těchto tvz. stránek se do těch procesorové cache moc nevejde. To pole bude o velikosti 1 nebo maximálně 2.
Sorry ale řídím se heslem kdo tomu rozumí umí to i provést, jinak jsou to jenom kecy zakomplexovanců, kteří si akorát honí ego a nic neumí. Umíš to provést? Pokud ano, zveřejni zdroják jak bys to dokázal. Že se naučíš nějaké fráze zpaměti ještě neznamená, že je chápeš. Protože to co tu čtu, zde na rootu je to skoro samý expert na architekturu procesoru, že by nám v ČR tyto mozky i Intel mohl závidět.
Pane kolego, skoro mám až pocit, že trpíte stejným problémem jako řada studentů prvního ročníku FI MU když na písemce dostanou jakoukoliv otázku na pomezí hardware/software. Nebudu se vám snažit vysvětlit princip Meltdown ani Spectre, to už zkoušeli jiní. Jen si dovolím uvést na pravou míru pár zásadních věcí.
1) 4096B = 4KiB; tech se do cache procesoru vleze vcelku dosti.
2) Virtuální paměť není, nikdy nebyla (a doufám že ani nikdy nebude) soubor na disku. Swap (resp. swapování stránek) funguje, pravda, díky virtualizaci paměti, ale opravdu to virtualizace paměti není. Virtuální paměť není nic jiného, než logický adresní prostor, který je mapován na fyzický adresní prostor vlastní RAM paměti. Pěkný úvod do problematiky najdete třeba na wikipedii: https://cs.wikipedia.org/wiki/Virtu%C3%A1ln%C3%AD_pam%C4%9B%C5%A5
P.S. Toto není o tom, že by na root.cz byl samý expert. Znalosti, na které se článek odkazuje a které - jak se zdá - postrádáte, jsou běžnou součástí bakalářského vzdělání v informatice či informačních technologiích. A také, běžnou komoditou lepších průmyslových škol s IT oborem. Další reakce se zdržím, neb mám pocit že reaguji na trola. Ale ten nesmysl se souborem na disku už se snažím vymýtit dlouho.
Virtuální paměť není, nikdy nebyla (a doufám že ani nikdy nebude) soubor na disku.
Dobrý den, nechci vůbec polemizovat s tím, co se má označovat za "virtuální paměť", ale tento pojem pro swap, co já pamatuji, zaváděl už Macintosh ve verzi 6 nebo 7 určitě, Windows mají také nastavení swapu (stránkovacího souboru) na kartě "Virtuální paměť". Patrně málokdo umí rozlišit, že odkládání stránek na disk je podmnožina možností práce s virtuální pamětí, když výrobci OS to takto zjednodušují.
Minimálně bych byl shovívavý k tomu, že tyto pojmy u neodborné veřejnosti splývají (vs. vyjádření, že "nikdy nebyla (a nikdy nebude)"), protože pojmenování v rámci OS, které jsou používány miliardami lidí, je jistě také dost relevantní pramen.
Bohužel byste opravdu potřeboval tu problematiku nejdřív trošku sám nastudovat, protože to je jedna perla vedle druhé:
> 4096B = 4MB
Chápu, že v 5 ráno to mohla být neúmyslná chyba... ale 4096B = 4kiB
> virtuální pamět a swap
Virtuální paměť je o mapování logických adres procesu na fyzické adresy v RAM pomocí MMU [1], tj. každý proces může mít na nějaké logické adrese jiná data a nevidí do dat ostatních procesů. Máte pravdu, to mapování nastavuje kernel. A to tak, že tam je dostupná celá RAM [5]
(řádek 7).
Swap je záležitost operačního systému a může být implementován různě. Z dobrých důvodů používá stejnou velikost stránek a je úzce svázán s tím jak operační systém řídí mapování v MMU [6].
> číst cache
Nikdo v popisovaném útoku nečte přímo data z cache procesoru, testuje se pouze přítomnost stránky v cache pomocí časového útoku Flush & Reload [4].
A jedna perla z předchozích příspěvků:
> ASM možná může do cache, C a vyšší jazyky ne
Není vůbec žádný rozdíl v tom co může ASM a co může C nebo třeba C++ (nebo Java a Python, když víte jak). Na konci z toho jsou úplně stejné instrukce pro CPU (strojový kód) a ta cache měla být kompletně transparentní (ten Flush-reload útok [4] právě zneužívá toho, že úplně není).
Zdroják tady nikdo od nás zveřejňovat nebude, nemáme zájem na šíření exploitů. Meltdown je snadné zreprodukovat s minimálními znalostmi architektury. Pseudoalgoritmus jsem Vám ukázal. Nic složitějšího tam není.
Mimochodem se prakticky všechny ty architekturní detaily návrhu CPU učí třeba na FIT VUT. Funkce MMU a struktura TLB už na bakalářském stupni - třeba tady [2] a tady [3]. Tolik k "expertům".
[1] https://en.wikipedia.org/wiki/Memory_management_unit
[2] ITP - http://www.fit.vutbr.cz/study/course-l.php.cs?id=12200
[3] IOS - http://www.fit.vutbr.cz/study/course-l.php.cs?id=8006
[4] Flush-reload: https://www.usenix.org/node/184416
[5] https://github.com/torvalds/linux/blob/master/Documentation/x86/x86_64/mm.txt
[6] https://en.wikipedia.org/wiki/Paging
Jednotky KiB, MiB, ..., byly zavedeny (standardizovány) poměrně pozdě, někdy před zlomem milénia. https://en.wikipedia.org/wiki/Binary_prefix
Existuje tedy obrovská spousta poměrně "moderní" literatury, která ještě pracovala s tím, že čtenář ví, že 1 "starý" kB = 1024 B = 1 KiB.
Dodnes se setkáte s tím, že někteří lektoři to učí špatně, nebo ne dostatečně vysvětlují problematiku.
Také se to nijak neodlišuje v mluvě. Když řeknete "kilobajt", každý si musí umět představit 1024 bajtů. Ještě jsem neslyšel, že by někdo mluvil o "kilo-binární bajt".
Aby to dál nebylo jednoduché, nejrozšířenější operační systém nazývá kilobajtem 1024 bajtů (z Francie do Redmondu ještě nedošel dopis o zavedení binárních prefixů), a aby to bylo ještě jednodušší, tak už před zlomem milénia naopak výrobci disků začali naopak využívat toho, že mohou prodávat X gigabajtové disky, které ale měly "z úsporných důvodů" GB počítáno podle SI, tedy x1000^3, namísto tehdy běžných x1024^3.
Myslím, že odborný čtenář dokázal jak v minulosti, tak dnes rozklišit, kdy je prefix myšlený jako binární. Ve skutečnosti je to nutno rozlišovat jedině tam, kde měříme nějakou skutečnou alokaci - např. velikost souboru, velikost disku, pamětí... A ani v tom není pořádek. Výrobci RAM modulů uvádějí velikost v GB z podstaty věci 2^x (konstrukce RAM to jinak neumožňuje), výrobci rotačních disků jako 10^x (kostrukce to umožňuje a oni mají vyšší zisk), a výrobci flash medií - tam nevím, nezkoumal jsem to.
Je v tom, i po 20 letech, neskutečný bordel.
"Existuje tedy obrovská spousta poměrně "moderní" literatury, která ještě pracovala s tím, že čtenář ví, že 1 "starý" kB = 1024 B = 1 KiB."
Ti to nějak šilhá.
1000 B = 1 kB
1024 B = 1 KB
Existuje obrovská spousta "nemoderní" literatury kde se tohle dodržovalo, a stejná nebo ještě větší spousta, kde to bylo blbě. Hlavně v té "pseudoodborné".
Dneska podle toho holt poznáš nevzdělané lamy od informovaných jedinců, například já binární předpony používám i v mluvě. Obzvlášť gibibajt zní noc hezky, na tom si vždycky vychutnávám užaslé oči těch lam :-D
Obzvlášť gibibajt zní noc hezky, na tom si vždycky vychutnávám užaslé oči těch lam :-D
Jojo, dělat z lidí lamy (za mě se říkalo "debily") svede kde kdo.
Gibibajt, kibibajt se podle mě v mluvě neuchytilo. Byl to sice pokus, jak to vyřešit "vyslovitelně", ale nevěřím, že se to ještě kdy k životu přivede.
Tak mi řekněte, jak vlastně "gibibyte" vyslovujete. Česky by to bylo [gibibite], ale [bite] není moc v módě, uchytilo se univerzální anglické [bajt]. Ale pak si u předpony "gibi" musite vybrat. V USA, kolébce IT technologií by řekli [gibibajt]. Ve Francii, kolébce Le Système International d'Unités (SI) by řekli [džibibajt]. V dalších anglicky mluvících zemích by řekli až [džibájbajt].
Je možné, že některé Vaše IT-lamy nejsou zas až tak jazykovými lamami. Je dokonce i možné, že Vás nazývají lamou, právě kvůli neznalosti jazyků.
Binární prefixy se v jazycích moc neuchytily. Buďto jsou jednotky používány ve smyslu, kde není rozdí podstatný ("Adodbe má !šest! [gigabajtů] instalátor - není pro sdělení rozhodné, jestli se jedná o 6 GB, nebo o 6 GiB), nebo je to zřejmé z kontextu (o adresaci paměti budete vždy mluvit v binárních prefixech). Případů, kde dochází k překryvu, je minimum.
Je to podobné, jako když řeknete "pojedu autem". Ze sdělení není jasné, jestli podejedete osobním, či nákladním. Nebo jestli sedanem, coupé, kombíkem, fourgonem, či valníkem. Většinou to buďto vyplyne z kontextu, nebo to není vůbec důležité. Nematlejte dohromady jazykovědu a IT, prosím.
Stránka není datový typ. Je to organizační jednotka paměti v x86 MMU. Viz např. http://wiki.osdev.org/Paging .
"Sorry, netuším co si představuješ pod pojmem stránka. Takový datový typ neznám. Není projevem chytrosti operovat s významy které nejsou obecně vyjádřené. Jinak dochází ke zmatení pojmů."
K žádnému zmatení nedochází, stránka je desítky let zavedený a používaný pojem v oboru správy paměti. Nejde o projev jeho chytrosti, ale tvé neznalosti.
technomaniak: odkdy je potřeba mít publikaci, abych dokázal svoje znalosti a odkdy je potřeba vůbec svoje znalosti někomu anonymnímu dokazovat? Převedl jsi tady neznalost elementárních věcí a nejsi s to pochopit problematiku, odbornou publikaci nejsi schopný z hlediska odbornosti očividně ani posoudit, raději ostatní jen urážíš.
Proč bych nosil dříví do lesa? Znovu opakuji, že nejde o žádné expertní znalosti, ale o naprosté základy, které byly mnohokráte popsány v hromadě knížek ve všech možných jazycích, včetně češtiny (namátkou Donovan, Madnick: Operating Systems. McGraw-Hill, 1974 - český překlad vyšel v roce 1983 v SNTL - za dob mých studií povinná literatura; nebo třeba Čada: Operační systémy. Grada, 1994). Pokud si pleteš stránkování paměti s odkládacím prostorem, tak bych ti ty základy doporučoval nastudovat, když už se chceš k dané problematice vyjadřovat, místo toho tvého štěkání tady.
Podle původních popisu jsem myslel, že se ty data v cache využívají lehce jinak, teď to konečně chápu.
Je to sice hooodně kostrbaté a pomalé, ale pokud ty data někdo chce získat, tak to tímto zjevně jde.
jen mě napadá, máme OS s multitaskingem, tj pokud na stejném procesoru běží ještě další úlohy, které intenzivně přistupují do RAM, tak ten obsah cache může expirovat dříve, než to stačím otestovat (tohle hodně záleží na algoritmu alokace cache a v jaké úrovni cache se načtená paměť nachází L1-L2-L3)
a ještě mě napadá, pokud každá buňka v cache bude kromě informace z jakého místa v paměti je bude mít i informace, z jakého ringu/urovně přístupu je získána, zda to při dalším použití této informace pak nevyvolá patřičnou vyjímku a neznemožní toto využití. Předpokládám, že nějak takto to má AMD ošetřené a proto není touto chybou zasažen...
Mrkni na aj diskus pod clankom
asi najhutnejsi popia pre beginera
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
To bude trvat. O postranních kanálech na cache jsem četl kolem roku 2014 (Flush+reload - 2014, Prime+probe - 2015), přesto to nikdo moc neřešil. A to tyto studie navrhují řešení, jak tyto útoky omezit, nebo jim zabránit. O meltdown a spectre se údajně ví asi rok a to není dost času na změnu architektury CPU, v tom má intel pravdu, ale o těchto postranních kanálech ví nejméně 3 až 4 roky a skutek utek.
Zajímalo by mě, jak chcete zabránit časovému "útoku" na cache? Vždyť urychlení je podstatou té cache (a všech moderních postupů HPC programování, které se snaží tu cache využít na maximum). Můžete předejít měření času, tu cache úplně vyhodit nebo nějak zásadně změnit celou architekturu, aby byla důsledněji oddělená data i adresy. Ale těžko to uděláte za rok (nebo za pět).
Kto ma vratit CPU? End useri? A koho investicia bola zmarena? Akcionarov Intelu?
Ja si stale nie som isty ze ci za chybu ktora je opravitelna softwareovo je zodpovedny vyrobca HW. To mate ako s modnou obuvou. Kupujete topanky ktore maju vyrobcom definovane parametre a jednym z nich je ze ich nemozete nosit casto (kazdy den). Ak sa rozpadnu z dovodu opotrebenia, nevyreklamujete ich. Tak isto CPU ma nejake parametre ale niekde nie je uvedene ze jednym z nich je ze sa postrannym kanalom neda precitat cache. Intel moze argumentovat ochranu pred tym ma riesit operacny system. A ze sa znizi vykon? Tak doteraz ste vyuzivali vykon nad ramec toho co predpokladal Intel a patchom sa dostavate len na tu spravnu hodnotu vykonu ktoru ste mali ocakavat Vy.
Ze su v CPU bugy - ano, ako vsade inde. Ale Intel nie je v situacii kedy by nieco musel. Moze, ale ci si naozaj nasype popol na hlavu a nieco sa zmeni - to uvidime.
Pokud má procesor zabudované mechanismy ochrany paměti, a pak je špatně implementuje a lze je obejít, je to chyba procesoru. Ty SW opravy nahrazují ochranu paměti, která je špatně implementovaná v procesoru, a dělají to za cenu nevyužití plného výkonu procesoru.
Je to, jako byste koupil auto se špatnými brzdami (špatný HW) a řešením by bylo jezdit maximálně pětikilometrovou rychlostí (SW řešení). Taky byste tvrdil, že výrobce auta je vlasně OK, když se problém dá vyřešit změnou používání HW?
Ale Intel je implementuje přesně podle ISA.
Je to, jako kdybyste koupil zámek nějaké kategorie zabezpečení a následně někdo vynalezl bumping. Taky byste tvrdil, že všichni výrobci by měli vracet peníze za zámky (když při výrobě nikdo netušil, že nějaký bumping existuje)? Oni neslibovali, že to je odolné proti bumpingu. No a u těch procesorů máte tu výhodu, že existuje SW upgrade, takže je to něco v tom stylu, že můžete ten zámek upgradovat, odolný proti bumpingu bude, ale při otevření si 15s počkáte.
Takže ano, já bych v takovém případě tvrdil, že výrobci zámků fakt za nic nemůžou.
Proč? Připomíná mi to tohle: https://www.youtube.com/watch?v=q8LaT5Iiwo4
Rozumíte vůbec tomu problému?
Jsem jenom koncový uživatel, který zaplatil za produkt. Kdo si myslí, že např. sjeté brzdové destičky je nejlépe řešit softwarově je podle mne mimo. Jste v bublině Intelu nebo co?
Do křemíkového waferu se FYZICKY vyleptá určitý tvar vycházející z optimalizovaného návrhu zapojení tranzistorů. Představuji si to jako matici logických hradel. To je softwarově neopravitelné.
Jsem jenom koncový uživatel, který zaplatil za produkt. Kdo si myslí, že např. sjeté brzdové destičky je nejlépe řešit softwarově je podle mne mimo. Jste v bublině Intelu nebo co?
Do křemíkového waferu se FYZICKY vyleptá určitý tvar vycházející z optimalizovaného návrhu zapojení tranzistorů. Představuji si to jako matici logických hradel. To je softwarově neopravitelné.
Není to tak úplně pravda. Příkladem jsou výrobci automobilů, kteří právě při stížnostech zákazníka nahrávají novější software. Dokonce, u některých řídicích jednotek neexistuje jeden nejnovější software, ale třeba pět variant - a nahrává se taková, podle druhu stížnosti zákazníka. Např. jeden software, když si zákazník stěžuje na spotřebu, jiný, když na hluk, jiný, když převodovka příliš citlivě podřazuje, ..., protože nastavení se navzájem vylučují.
Zrovna u brzdových destiček jste se velmi trefil. Firmware řídicích jednotek automatických převodovek neustále řeší, kdy (jestli vůbec) zařadit volnoběh, kdy podřadit a pomoci brzdnému účinku (a šetřit brzdové destičky :), kdy řadit vyšší rychlost místo volnoběhu (zastavení vstřiku paliva za cenu vyššího odporu motoru), ...
Vracení peněz není jednoznačné. Pro vznik odpovědnosti za škodu musí existovat zavinění minimálně v rovině nedbalosti. Vzhledem k tomu, že tento bug se objevil vývojově, existoval spoustu let bez povšimnutí kýmkoliv, tak bych řekl, že zavinění nebude vůbec existovat (resp. bude v rovině běžné nahodilosti).
Nemusí. To se Vám celou dobu snažíme vysvětlit. Intel nikdy netvrdil, že jde o kryptograficky bezpečný procesor bez možnosti útoku postranním kanálem a bez bugů. Ta chyba je společná a v jiné formě je přítomná i na některých ARM a Power čipech. A Linux by zase nemusel mít namapovanou celou fyzickou paměť (a na 32bit systémech ani neměl).
Ten procesor funguje jak má a objevil se úplně nový typ útoku. No smůla... to se občas stane. Stejná situace nastala ve chvíli, kdy začala být možná dostatečně přesná analýza spotřeby. Taky nikdo nevracel peníze. Ani výrobci čipových karet (třeba Mifare za původní DESFire, která byla přes měření spotřeby napadnutelná).
Každý výrobek a software se prodává bez informací o v budoucnu objevených chybách... nebo vy máte křišťálovou kouli?
Ta analogie s bumpingem je ve skutečnosti hodně přesná. CPU od Intelu splňuje přesně to co splňovat má. Jen to s dnešním výkonem, rozlišením časovačů a tímhle objevem přestalo být dostatečně dobré samo o sobě a musí pomoct i SW vrstva a neumožnit nebezpečné operace.
Mimochodem, všechny CPU pořád podporují kompletně nezabezpečený reálný mód (DOS). Je to bug? Nebo starost OS? Tohle je totiž úplně stejné, budeme muset vymyslet (všichni) jak psát programy a OS trošku jinak. Stejně jako se to stalo po objevu power analysis útoků. Svět se prostě vyvíji...
Základní poučka z kryptografie - všechno se dá napadnout, pokud se to útočníkovi vyplatí
MarSik: "Každý výrobek a software se prodává bez informací o v budoucnu objevených chybách... nebo vy máte křišťálovou kouli?"
Si děláš srandu? Intel podle tebe nevěděl, že v průběhu zpracování při spekulativním provádění jsou okamžiky, kdy se neprovádí kontrola oprávnění? A kdo jinej by to měl proboha vědět když ne právě návrháři těch čipů?
Srovnání s DOSem mi příde mimo. U DOSu všichni tak nějak vědí, že běží v nechráněném reálném módu. Ale u současných systémů se spoléhá, že jsou práva patřičně ošetřena.
Věděl a věřím, že taky popsal v datasheetu (ten není snadné najít). A všimněte si, že k té hodnotě se dostanete jen bočním kanálem. Pokud se ten kód skutečně provede, tak to CPU zařízne. Takže i když se oprávnění nekontroluje, nikdo se k těm datům neměl mít jak dostat.
Srovnání s DOSem není mimo, spekulativní provádění instrukcí se taky dá vypnout. A dnes všichni ví, že nechráněný reálný mód je nebezpečný. Za 20 let budou všichni vědět, že je potřeba chránit i cache a že to za snížený výkon stojí.
Javascript se přinejmenším v Chromu překládá před spuštěním JIT kompilátorem do strojového kódu (assembleru). Je to pěkně popsáno v https://spectreattack.com/spectre.pdf
Mě stále není jasné, zda je nutné nějak zalepovat i prohlížeč, nebo zda stačí zalepit OS. Logika napovídá, že by mělo stačit zabezpečit vyšší vrstvu - OS, je to tak? Pak ale nechápu, proč třeba MS, FF i Chrome vydávají aktualizace prohlížečů. Je to čistě prevence pro ty, co nemají zalepený OS? Nebo je to nutnost?
pokud jde o tenhle případ s variantou 2 u spectre, každý kdo generuje ASM kód musí udělat "zalepení", aby nebyl schopný vygenerovat takhle zneužitelný kód. Je to doslova záplata na tuhle konkrétní chybu, gcc i lvm již patch mají v upstreamu. Stejným způsobem záplatou musí/mohou udělat všechny js enginy.
Jsem blbej, ale stále tomu nerozumím. Pokud je nutné rekompilovat aplikace, tak to přeci není žádná oprava, protože útočník to samozřejmě dělat nebude a závadnou aplikaci a bude ji distribuovat. Takže to musí odchytit OS nebo nějaká nižší vrstva, jinak to nemá cenu.
Pokud má browser pro TABy (nebo třeba rozšíření) oddělené procesy, tak by oprava OS přeci měla stačit (viz předchozí bod). Pokud pro TABy používá jeden proces, tak je zase využité těchto dvou chyb "zbytečné", protože to má v rámci jednoho procesu.
Co jsem pochopil, tak rekompilovat aplikace je nutné z toho důvodu, aby z jiného procesu nebylo možné přečíst paměť té rekompilované aplikace.
Pokud jde o browser, tak ono i když to budou oddělené procesy, tak mohou mít nějakou Shared paměť s citlivými daty, ale i v tom jednom tabu mohou být v paměti třeba jména/hesla k web stránkám. Jde o to, aby Javascript nebyl schopen přečíst paměť browseru a výsledky odeslat hackerovi.
útočník musí svůj kód propašovat na tvůj CPU, otázka je jak to udělat, buď tam má přístup spustí si tam cokoliv, pak je potřeba oprava cpu, mikrokódu, obrana v kernelu nebo cokoliv další. Nebo třeba útočník může svůj kód spustit přes prohlížeč na svojí webové stránce, kterou navštívíš a tady je možná oprava překompilací prohlížeče, tak aby nebyl schopný vygenerovat ASM instrukce v takovém uskupení, že by zneužily slabinu. Je to částečně záplata, ale i to se počítá.
Ty patche do browserů jsou hlavně o stížení napadení, útočník potřebuje například velmi přesný časovač, který ty patche odstraňují (Chrome i Safari znepřesnili časovače na 1 milisekundu). Pak se tam dělají další úpravy které znemožní konkrétní útoky, například použití operátoru bitové and u spekulace na array bounds a podobné. Celkem pěkný článek s JavaScript příklady je:
https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/
Tím si nepomůžeš, exploity které jsem dosud viděl ani hrtimery nepoužívají - využívají k měření přímo x86 instrukci RDTSC a nevím o tom že by šlo jejímu použití nějak zabránit. I kdyby to šlo, stejně můžeš měřit čas počítáním počtu průchodů cyklem na druhém jádře a v tom už ti opravdu nikdo nezabrání.
Článek je celkem o howně. Čekal jsem něco odborného a ne jen obecné řeči.
Nekritizuju redakci ani v nejmenším, jen mě trochu zklamal..
Dostupné patche do jádra jsem zatím nijak nezkoumal a ani je zatím neinstaloval(jen s povděkem přijal, že to bude možné i vypnout) - čekám až se situace trochu stabilizuje.
Nemám tedy ještě úplně jasno s následující situací:
Pár let staré PC u kterého se nedá očekávat, že by výrobce vydal update firmwaru s novým mikrokódem. Řeší patche do jádra např. Meltdown i bez mikrokódu? Bude mikrokód součástí distribučního initrd(initramfs)?
Co jsem koukal na ty poslední merge, tak jediné, co ten patch dělá je invalidování cache. Takže ano.
jinak mikrocode může aktualizovat i os, jak windows, tak linux.
https://wiki.debian.org/Microcode
Musíte to instalovat ručně, default to není, protože GPL :/
Neexistuje zatím oficiálně, ale bylo by bez problému přijato: http://www.ujc.cas.cz/jazykova-poradna/dotazy/0066.html
samozrejme, ze existuje: https://www.nechybujte.cz/slovnik-soucasne-cestiny/barista
Zatimco lizat anal nepotrebnym novatorskym pseudo-vyrazum ktere existuji jen proto aby bylo mozne lestit prd je znamkou distingovanosti a vzdelani, ze ?
Navic to vypada ze jste zapomel na sve skvele Vzdelani, a nezeptal se se zda k tomu chce hranolky ... Zpatky do McSkoly, "akademiku".
Koukal jsem se na akcie intelu za posledních 6 měsíců a nějak nevím, za co by měl být popotahován? Ten pokyn na prodej dával někdy na konci října, proběhlo to na konci listopadu, cena akcií je teď prakticky na stejné úrovni. Na čem teda konkrétně měl vydělat?
Sdělit to nemohl, protože na to měli embargo. Podobné security embarga asi budou častější, tak aby nakonec nebyl závěr, že CEO nesmí nikdy nic prodávat...
to musí posoudit komise, problém to být může nebo nemusí. Takhle chyba se netýká pouze Intelu, dopat na akcie se uvidí časem, ale je možné, že nebude velký. Kvůli očekávané chybě, o které očividně dopředu vědělo více HW výrobců nemůžeš přece na rok a více zmrazit prodej akcií.
Každopádně to je podezřelé, ale není na nás to posoudit.
Intel mal info od googke od Juna, nahlaseny predaj akcii resp. nejake automatickej sttategie pre portfolio oznamil v Oktobri, predal v Novembri alebo tak nejak
V kazdom pripade mal cca 4-5 mesiacov na setup strategie portfolia aby predaj nevyzeral ako zneuzitie insider info
No ked mu toto prejde ... Snad najdu nejaky precedens ... Alebo si ho panko nasiel dopredu a je v tom vopred cisty
Jsem stařec a BFU, takže si umím představit reakce :-)
Spectre a Meltdown? Podle mne jde jen o špičku ledovce, lidstvo v podstatě ztratilo pud sebezáchovy, vytratily se mechanismy nutné k dlouhodobému přežití 'západní' společnosti.
Se složitostí systémů zákonitě roste chybovost a klesá ověřitelnost. Narůstají nezamýšlené vedlejší účinky, až tyto postupně převáží původní (třeba i chvályhodné) záměry. A z různorodosti se postupně stává spíš zrůdnorodost.
Jsem sice laik, ale nepřijde mi normální, aby v procesoru běžel nekontrolovatelný operační systém (MINIX). Respektive aby tam běžel jakýkoliv OS.
A je normální, aby telefon měl procesor s 8 jádry, 15 mega foťák s optikou vhodnou leda tak pro dětskou hračku a HD rozlišení displeje? Ano, dobře se to prodává...a o to jde. Nenajde se nikdo, kdo by dal přednost zdravému rozumu před krátkozrakým komerčním úspěchem, na to společnost nemá mechanismy.
Už jen čekám, kdy nám někdo začne vnucovat zařízení, která budou bootovat jen po síti, aby se zase ztížila možnost unikat zájmům Velkých bratrů. (Včetně řešení termínované životnosti zařízení.) To vše samozřejmě pro dobro uživatelů.
Současná technická civilizace vznikla z velké části i díky standardům a normám. Když je ale standardů třeba sto, tak to znamená, že prakticky není žádný. A taková mi připadá i situace v IT. Např. z prohlížeče se stalo monstrum, které se snaží tento chaos nějak zvládat.
IT podle mne v poslední době přináší čím dál tím méně nové skutečně užitečné funkčnosti a čím dál více módních nesmyslů a problémů (třeba bezpečnostních děr).
Protože existují věci jako Kolibri OS, tak si myslím, že vše by se (teoreticky) mohlo ubírat i jinými cestami, přibližně o dva řády méně náročnými na výkon. Pak by se věci typu spekulativního vykonávání instrukcí vůbec nemusely řešit. Ale za současného stavu se problémy napravují dalším zvyšováním složitosti, takže asi musíme počkat, až se celá ta pyramida 'technologií'(hlavně že pro každou pitomost máme vznosný název...newspeak), abstrakčních vrstev a pseudostandardů zhroutí a někdy někdo začne znovu...
Pokud vím, tak se kdysi řešívalo, kolik andělů se vejde na špičku jehly...a při těchto disputacích se jaksi pozapomnělo, že špatně by mohlo být i samo základní paradigma.
Proč by měl být zavirovaný? Ale i kdyby, je to jedno. Nejde o prakticky použitelný OS, ale o ukázku, jak úsporně lze software psát. Samozřejmě si nemyslím, že by se všechno mělo dělat v assembleru. Na druhé straně je ale také zřejmé, že dnešní software je řádově 'rozežranější' než by měl (a mohl) být.
Tak k tomu BFU, aneb řekl sis o to:
Mobily:
- 8 jader - tady je hlavní chyba, že se tomu stále říká telefon. Je to normální kapesní počítač (pro někoho elektronický organizér, pro jiného gameboy) s funkcí telefonu.
- 15Mpx foťák se tam dává právě kvůli té špatné optice. Aby z toho po zabudované softwarové úpravě lezly alespoň trochu koukatelný 2Mpx fotky.
A to že se preferuje móda před funkcí? To není jen IT, to je ve všech oborech tak nějak stejné (s výjimkou těch několika málo oborů, které se zajímají jen o funkci). Výše najdete příklady jak auto-moto, tak bot. Namátkou mě napadají třeba tramvaje Škoda 14T, kam se vejde 210 osob k stání, ale jen když tam nikdo nesedí a když se někteří stojící rozsekají aby ideálně vyplnili příslušný prostor.
Mobily:
S rozumně napsaným softwarem by i hodně všestrannému zařízení stačil jednojádrový procesor bez spekulativního vykonávání instrukcí. Navíc bychom méně nabíjeli a nemuseli se zabývat např. půšvihy z tohoto článku.
Foťák:
Nesouhlasím. Špatnou optiku takto nelze kompenzovat (viz např. Hubble). Naopak malý snímač s neúměrně vysokým rozlišením má velký šum a zhoršuje tak zejména snímky za horšího osvětlení.
Podle mého názoru je velký výkon telefonu potřeba snad jen na hry. Problém je, že si nemůžeme vybrat. U počítačů (zatím) volbu do jisté míry máme ('herní'/'kancelářský'). U mobilů nikoliv. Prostě si nemohu vybrat slušný telefon 'pro nehráče' s lepší výdrží baterie atd. Buď si koupím levný (prakticky nepoužitelný) šmejd s malou pamětí atd. nebo něco 'lepšího', ovšem s přívažkem absurdního procesoru, foťáku a spotřeby.
Prohlížeče:
Tady nejsme ve sporu. Jen každý píšeme o jiné straně jedné mince. Prohlížeče jsou samozřejmě pachatelem i poškozeným... a přijde mi zbytečné rozebírat, jestli byla první slepice nebo vejce.
Jinak s Vámi naprosto souhlasím, 'technická dekadence' je všudypřítomná. Třeba auto už není dopravním strojem, ale módním doplňkem k rychlé spotřebě. Jenže se už kašle i na základní věci, které ovlivňují ergonomii a bezpečnost. Třeba výhled, bezpečné osvětlení atd. Také se zapomnělo, že občas padá sníh nebo že ve městech jsou obrubníky...
Mobily: když si zkusíte nějakou šunku, tak zjistíte, do čeho vlastně ten extra výkon jde - do plynulosti uživatelského rozhraní. Bohužel je to moderní trend, že to celé musí být barevné jak omalovánky, animované a hlavně rychlé. Člověk má ve složce 1000 fotek, chce thumbnaily, 12 na stránku, a pak prostě listuje tím, že píchne prstem a rychle hne nahoru a pustí. A čeká, že se mu přelistuje X stránek a na všech thumbnaily. Tahle věc ale žere neskutečně výkonu a baterky - načtení fotek, příprava thumbnailu, sto souborů za vteřinu a ještě vše hezky rozanimovat.
Foťák: ale právě že to pomáhá. Moderní trend je co největší světlost objektivu a udělat několik snímků s různou dobou expozice. Z toho se pak dopočítá fotka ve vyšší kvalitě, než by tomu snímači odpovídalo. Ty algoritmy samozřejmě podvádí - jsou prolezlé věcma jako je detekce a zvýraznění hran atd. Všiml jste si, že některé mobily dokonce mají ze zadní strany fotoaparáty dva? Přidejte fakt, že ten šum není až tak náhodný a zkreslení objektivu je dokonce konstantní, a s dostatečně výkonným procesorem dokážete většinu problémů kompenzovat. Výsledná fotka pak sice není věrná originálu, ale vypadá dobře. A o to jde. Kdybych to přirovnal k fotce vesmíru: dostanete nádhernou fotku oblohy, kde ale třetina hvězd chybí a naopak vám tam přebývá pár hvězd, co neexistují. Jak moc ten mobil upravuje fotky se pak pozná na videu. Není výjimkou, že tyhle lepší foťáky produkují video v horší kvalitě, než ty pár let staré. Další věc jak si všimnout, jak moc foťák podvádí, je fotografování vzorů - to byste nevěřil, jak dopadne třebas fotka několika tanečnic v kostkovaných sukních.
K těm andělům.
Ona ta disputace není asi historicky doložena. Ale kdyby byla, tak mi to přijde jako dobrý myšlenkový úvod k limitám a diferenciálnímu počtu, který zpracovali Newton a Leibnitz.
Maxwell prý své elektromagnetické rovnice formuloval tak, že si představoval kola a táhla (nebo tak nějak).
Historická doložitelnost oné disputace není podstatná. Podstatné bylo dlouhodobé dogmatické lpění na (z dnešního hlediska) absurdním náboženském paradigmatu (a snah o jeho nesmyslné rozvíjení i v době, kdy už to bylo zjevně neudržitelné). Jak víme, vedlo to k hodně mrtvým.
Souvislost s myšlenkovými pokusy, modely a analogiemi ve vědě tady nevidím, ty jsou používány jen jako prostředek a nikoliv cíl...a nikomu tedy přímo neškodí.
Meltdown lze použít jen v případě, že jádro má přimapovnou k procesu tu část, kde drží tajné informace, hesla, a zároveň obsahuje konkrétní nebezpečnou část ať už přímo, nebo se poskládá pomocí nějakého skoku někam doprostřed kódu nebo instrukcí return a nebo obsahuje celý JIT compiler, což je největší kravina linuxového jádra, který umožňuje vnutit jádru vykonat uživatelský kód v ringu 0.
Kdyby jádro mapovalo jen to, co bezpodmínečně nutně potřebuje k zajištění služeb a počítalo rovnou s tím, že ta paměť je defacto read only, tak by nikoho ta chyba netrápila.
Spectre je totéž, jen se to týká jen aplikací, které vykonávají cízí kód dodaný z venku. Bez Meltdown se v zásadě omezuje jen na proces ve kterém běží. Takže je to věc prohlížečů a různých interpretů, kde vstup dodává třetí strana. Sandbox a bariéry to řeší. Mimochodem, ten příklad co se uvádí u Spectre jako způsob proniknutí mimo vyhrazenou oblast, tak pokud to takhle někdo má naprogramovaný, že jen zkontroluje rozsah a když je to mimo tak to nijak neřeší (žádná výjimka, nic?), tak by si zasloužil pověsit za ... do průvanu.
To trénování skoků je sice hodně zajímavý problém, ale podle mě okrajový a pokud lze tabulku skoků vytrénovat tak, aby spekulativně provedla úplně něco jiného, než jí nařizuje kód, tak je to pořádná bota CPU vývojářů
"Mimochodem, ten příklad co se uvádí u Spectre jako způsob proniknutí mimo vyhrazenou oblast, tak pokud to takhle někdo má naprogramovaný, že jen zkontroluje rozsah a když je to mimo tak to nijak neřeší (žádná výjimka, nic?),"
Pokud to dobře chápu, tak se jedná o to, že pošlu do BPF kód, který vypadá jako "a=x[100] & 1;y[a]=1", a v kernelu se provede:
if (idx < 0 || idx >=limitX) return CHYBA;
a = x[idx] &1;
if (a <0 || a >= limitX) return CHYBA;
y[a] = 1;
...
Co by to mělo udělat víc?
No, jednak ten kód, na kterém to ukazovali byl BPF (tzn. zkontrolovaný interpretovaný jazyk, případně výsledek JITu), dále to může být výsledek JITu v javascript interpretru, takže to není, že by někdo ten kód "napsal", to je výsledek kompilace a každý jazyk si pak chování může implementovat různě (např. v Pythonu je C API prostě C, bez výjimek).
Druhak výjimky na Linuxu přes syscall obecně nejdou. Jestli ve Windows jdou výjimky do jádra netuším, vypadá to, že možná ano.
"Mějte ale na paměti, že většina z jejich tvůrců jsou lidé s akademickým vzděláním týkajícím se architektur počítačů. Minimálně jeden z nich má v této oblasti titul Ph.D. Nebuďte tedy nešťastní z toho, že vám bude trvat dlouho, než proniknete do všech technických detailů – je to velmi komplexní a složitá problematika."
Když děláte volný překlad, prosím Vás, upravte kecy pro "sněhové vločky" do českého prostředí. Tady ještě "buzerantská přecitlivělost" nedošla tak daleko jako "na západě" a češi pochopí, když tři zbytečné politicky korektní věty shrnete do jedné stručné ... "je to těžší odborné čtení" bez zbytečného pindání kolem, které má asi takový význam, jako varování abyste nesušili živou kočku v mikrovlnce.