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/