Joanna Rutkowska o architektuře Intel x86 (diskuse)

[pc2005]

AMD má něco podobnýho. Nebo SMM sinkhole je taky hustej.

[F]

“Considered Harmful” Essays Considered Harmful

http://meyerweb.com/eric/comment/chech.html

[ožralý Izidor]

Haha, to je dost dobrý. Díky.

[xm]

Hlavně se těším na její druhý paper k tomuto tématu, který má následovat hned v zápětí a kde by měla uvádět praktické možnosti obrany (vyžadující jen lehké úpravy hardwaru). Tenhle první paper měl být jen takový úvod do tématiky, který se poněkud protáhl Předehra k tomu druhému...

[HonzaRez]

První paper, druhý paper - dá se to říct nějak srozumitelně klingonsky...?

[xm]

Paper se používá naprosto běžně :-P Studie není v mnoha případech ideální překlad. Možná tak "výzkumná práce" nebo pojednání, ale ani to se mi moc nelíbí

[F]

Publikace. Ale paper (čti pejpr) se fakt používá..

[Drom]

V anglicky mluvících zemích zcela jistě.

[kyknos]

v cechach take

[Miloslav Ponkrác]

Ač jsem papír nečetl, tak s UEFI stejně ztrácíte nad počítačem kontrolu, a přesto to všichni berou jako super pokrok. Pak už vás nemá co trápit, protože stejně nad svým počítačem nevládnete, stejně jako operační systém nemá kontrolu nad počítačem.

A že dříve či později to do UEFI dojde u všech strojů je jasné.

[R]

Nad pocitacom nemas kontrolu odkedy Intel vymyslel SMM (dost davno: 386SL). UEFI na tom nemeni nic. Jedine Secure Boot - este to zhorsuje tym, ze spusti len podpisany OS (v praxi: Microsoftom podpisany OS).

[Mrkva]

Jedine Secure Boot - este to zhorsuje tym, ze spusti len podpisany OS (v praxi: Microsoftom podpisany OS).

V praxi jsem nevidel HW u ktereho by neslo ty MS klice vykopat a nahrat tam vlastni.

[Michal]

V praxi ide o kazdy kus HW, ktory je postaveny na platforme ARM a jeho vyrobca planuje podporovat Windows a chce aspon Windows 8 certifikacnu nalepku. Inak o tomto aspekte Secure Boot pojednava specifikacia v casti "30.3.2 Clearing The Platform Key" a pise sa tam, citujem

The platform key may also be cleared using a secure platform-specific method. When platform key is cleared, the global variable SetupMode must also be updated to 1.

Davam do pozornosti cast "may also be ...". Microsoft v pripade ARM based HW diktuje vendorom, ze tam nesmie byt moznost zmazat PK a prepnut platformu do Setup modu. Na platforme Intel tam samozrejme ta moznost stale je, predpokladam ze kvoli riziku pripadnych anti-monopolnych zalob ak by to bolo inak.

[pc2005]

tak s UEFI stejně ztrácíte nad počítačem kontrolu

AFAIK by ten ARC procesor měl mít vyšší prioritu (bus level) než klíče securebootu. Ale zatím...

a přesto to všichni berou jako super pokrok

Já ne, tvoje věta tudíž neplatí .

dojde u všech strojů je jasné

Ne pokud si postavíme vlastní.

[Jendа]

Není mi jasné, co UEFI změnilo. Co z toho nemohl už klasický BIOS?

[Jendа]

Ale i kdybyste bezpečný hardware měli, tak stejně nemáte software, který by na něm šel spouštět . Například tři kritické bugy v QubesOS (od autorky článku) za poslední rok: CVE-2015-3456, CVE-2015-5154, CVE-2015-7835, nebo dnešní díra v Linuxu CVE-2015-8025.

[Jendа]

A on se tomuhle svěřil provoz elektráren, vodáren, nemocnic a bank? What could possibly go wrong?

[Bystroushaak]

Podle mě je základní chyba už používání C/C++. Tyhle jazyky mají moc blízko k hardware a zanášejí do návrhu software lowlevel chyby, které nesouvisí s logikou (není to nevhodný algoritmus, ale bugy vyplývající z pastí jazyka).

[kyknos]

a v cem bys os psal? v jave? :D v tom pripade si koupim psaci stroj :)

[xm]

Např. Rust je memory-safe jazyk vhodný i na psaní low-level věcí jako jsou ovladače a kernel.

[kyknos]

The first "stable" version of the Rust, version 1.0.0, was released 2015-05-15

to nevypada jako zrovna zrala technologie :)

[xm]

Někde se začít musí Neříkám že to musí být zrovna Rust, ale ze současných jazyků je k tomu účelu řekl bych nejvhodnější (byť ho rozhodně nepovažuji za dokonalý a to že je dost mladý je také fakt).

[xm]

Jinak mám pro tebe pěkný citát:

C is a programming language for turning low-level byte arrays into security advisories.

        -- François-René Rideau

[Bystroushaak]

a v cem bys os psal? v jave? :D v tom pripade si koupim psaci stroj :)

Možností je víc, ale nechtěl jsem cílit na něco konkrétního.

Já vím, že C je rychlé a blízko hardware a tak, ale to jsou zároveň samé nevýhody, pokud ti jde o bezpečnost. Když se podíváš na většinu chyb, tak je to právě kudla do zad při manipulaci s pointery, buffer overflow a všemožné další debilnosti, které by se ti ani neměly stát. Vždycky se říká „je to chyba programátora, o tom měl přece vědět,“ jenže když si vezmem škálu, na které se to děje, tak je to ve skutečnosti chyba jazyka. Kdyby byla nějaká taková featura třeba v autě, nebo v letadle, tak by okamžitě došlo k zakázání celého modelu, nebo alespoň konkrétních featur. Ve světě software se řekne „je to chyba programátora, měl přece vědět, že při šlápnutí na plyn nesmí zároveň zatočit doleva, pokud mu k tomu navíc svítí světla, vždyť je jasné, že v takovém případě musí auto vybuchnout.“ To že je to 30+ let staré tomu taky zrovna dvakrát nepomáhá. Kompatibilita je sice super, ale jaksi se vytrácí možnost pokroku.

Americká armáda používá na kritičtější aplikace už celé desetiletí adu, což je třeba jedna možnost. Osobně si myslím, že je prohnilá celá současná architektura procesorů a pokud bys chtěl něco skutečně bezpečného, tak bys musel jít třeba k lisp machines, nebo něčemu podobnému, co dole nemá bytecode a pracuje to na vyšší úrovni. Třeba se i po desetiletích nudy dočkáme, až konečně skončí závod o nanometry a firmy budou zase nuceny jít do něčeho kreativního, co se týče architektury.

No, to bylo pár myšlenek. Jako vždy je jednoduché říct, že je něco špatně, ale horší ukázat, jak to dělat dobře. Osobně ale chápu Jendův hate, protože současný stav je z hlediska seriózní bezpečnosti dost špatný.

[kyknos]

jenze bezpocnost neni jedine, a dokonce asi ani to nejdulezitejsi, kriterium - urcite ne obecne

[Jendа]

Souhlasím, někdy se hodí drtit čísla nebo provozovat bloated aplikace. Podle mě by teď bylo nejlepší vydat se cestou QubesOS - malý hypervizor, který může být klidně pomalý (a úplně nejlepší by bylo, kdyby byl formálně verifikovaný, ale to je asi hudba budoucnosti), a který nastaví memory protection virtuálům, ve kterých poběží dnešní běžné systémy.

Bohužel jak jsem psal o pár komentářů výš, Xen, nad kterým je to postavené, měl letos tři chyby umožňující vylezení z VM…

[xm]

Formálně verifikované je třeba seL4 mikrojádro. A to by se místo Xenu IMHO použít dalo...

[Bystroushaak]

jenze bezpocnost neni jedine, a dokonce asi ani to nejdulezitejsi, kriterium - urcite ne obecne

Tak to ani netvrdím.

[Jendа]

V nových procesorech od Intelu existuje hardwarová podpora pro kontrolu rozsahů pointerů - takže mu můžeš říct „tady je buffer odsud potud“ a když sáhneš vedle, tak ti hodí výjimku. Dokonce už pro to je podpora v GCC (ale nevím jak je to s podporou v glibc). Prý to bylo už před mnoha lety v nějaké jiné architektuře, ale z neznámých důvodů se od toho upustilo.

[Bystroushaak]

Tak mě přijde, že tohle by měla být samozřejmá část programovacích jazyků (v D to tak je). Jenže v C chtěli ušetřit pár bajtů, k čemuž možná byl před 30 lety důvod, ale pak se to celý takhle posralo.

[Jendа]

Jenže v C chtěli ušetřit pár bajtů

Podle mě spíš než o bajty jim šlo o rychlost. Nebo alespoň dneska to tak je. Při každém přístupu to musíš zkontrolovat.

[pc2005]

Není v GCC ten check pouze softwarový?

[Jendа]

Na CCC o tom byla nějaká přednáška, pochopil jsem to tak, že to prostě naplní ty kontrolní registry.

[pc2005]

Link?

Jako třeba pro každý

mov eax,[ebx]

? To by muselo bejt příšerně pomalý.

[Jendа]

Intel MPX

Jak to přesně funguje nevím.

[Jendа]

(softwarově to snad emuluje valgrind)

[pc2005]

Tak "rozsah" pointerů šel dělat i na 386(286), akorát bys musel používat segmentovanou paměť. Tam sis mohl nastavit pro každej proces bázi a limit a všechno mimo to vygenerovalo vyjímku. Akorát od zavedení stránek se používá jen jeden segment pro flatmodel (ona ta správa paměti byla dost naprd technologicky).

BTW Kontrolu rozsahu zásobníku (jako pointeru) má tuším Microblaze, ale ten je jinak uzavřenej a pomalej (a řekl bych, že ostatní funkce ISA tu bezpečnost značně sníží ).

[cekk2123]

Joanna Rutkowska is a talent person. His work has reached tremendous achievements. I really admire him fireboy and watergirl.

[puka]

A very nice blog, I like the way you share very honestly and interestingly, through my blog I learned a lot of things. basketball legends

[emmawatson]

Your posts are very detailed and meticulous, hope that next time you will have more good articles to share with readers slope 2