Portál AbcLinuxu, 6. května 2025 01:34
Joanna Rutkowska, polská expertka na bezpečnost informačních technologií a vedoucí vývojářka open source operačního systému zaměřeného na bezpečnost desktopu Qubes OS, zveřejnila šestapadesátistránkovou studii Intel x86 considered harmful (pdf, epub, GitHub) věnující se (ne)bezpečnosti architektury Intel x86. [reddit]
Tiskni
Sdílej:
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.
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.
tak s UEFI stejně ztrácíte nad počítačem kontroluAFAIK 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 pokrokJá ne, tvoje věta tudíž neplatí
dojde u všech strojů je jasnéNe pokud si postavíme vlastní.
The first "stable" version of the Rust, version 1.0.0, was released 2015-05-15to nevypada jako zrovna zrala technologie :)
C is a programming language for turning low-level byte arrays into security advisories. -- François-René Rideau
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ý.
jenze bezpocnost neni jedine, a dokonce asi ani to nejdulezitejsi, kriterium - urcite ne obecneTak to ani netvrdím.
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.
mov eax,[ebx]? To by muselo bejt příšerně pomalý.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.