Jaderné noviny – 8. 11. 2012: Dohady kvůli UEFI secure boot

26. 11. 2012 | Luboš Doležel

Články - Jaderné noviny – 8. 11. 2012: Dohady kvůli UEFI secure boot  

Aktuální verze jádra: 3.7-rc4. Citáty týdne: Mel Gorman, David Miller. Omezení jádra pod UEFI secure boot.

Obsah

• Aktuální verze jádra: 3.7-rc4
• Citáty týdne: Mel Gorman, David Miller
• Omezení jádra pod UEFI secure boot

Aktuální verze jádra: 3.7-rc4

Aktuální vývojová verze jádra je 3.7-rc4 vydaná 4. listopadu. Linus k ní řekl: Je zajímavá pravděpodobně jen rozruchem, který způsobila v jistých kruzích, protože obsahuje opravu v žurnálování bitmapy na ext4. Je to drobný patch a navzdory vzniklému šílenství nebylo možné problém reprodukovat, pokud jste si nehráli se speciálními volbami pro mount.

Stabilní vydání: verze 3.0.51, 3.4.18 a 3.6.6 vyšly 5. listopadu. Všechny obsahují důležité opravy. Poslední dvě zmíněné verze obsahují opravu poškozování dat na ext4.

Citáty týdne: Mel Gorman, David Miller

Kdo nemá po ránu rád vůni formálních metod?

-- Mel Gorman

Kód pro metriku říká: „Yo dawg, I heard you like sizeof, so I did a sizeof of a sizeof, so you can size your size!“ Oprava od Juliana Anastasova.

-- David Miller

Omezení jádra pod UEFI secure boot

"Problém" s UEFI secure boot se linuxového systému dotýká na různých úrovních. Nejprve tu máme problémy s tím Linux vůbec spustit, které jsou snad povětšinou vyřešeny dvěma podepsanými zavaděči, které jsou k dispozici pro distribuce a uživatele. Pak tu jsou jaderné funkce, které mají potenciál sabotovat secure boot. V závislosti na pohledu na věc by tyto funkce buď měly být v jádře nastavitelné – aby je některé distribuce mohly u podepsaných jader vypnout – nebo nepředstavují větší nebezpečí než existující (nebo neznámé) chyby v jádře. Jak asi tipujete, tak na linux-kernel zazněly oba pohledy na věc.

Podstatou problému je to, že na linuxových systémech jádro uživateli root důvěřuje. To znamená, že root může ve stavu systému provádět různé dočasné – nebo trvalé – změny. Mezi tyto změny patří použití kexec() ke spuštění jiného operačního systému nebo zápis hibernačního obrazu na swapovací oddíl pro použití při obnově (resume). Ale obě tyto funkce může útočník použít k obejití ochrany, kterou má secure boot vynucovat.

Pokud by uživatel například spustil systém přes jeden z Microsoftem podepsaných linuxových zavaděčů – „vata“ (shim) nebo „předzavaděč“ – s jádrem, které neomezuje pravomoci roota, tak by toto jádro mohlo spustit jiné jádro, které třeba mohlo být kompromitováno. Horší je ještě to, že z pohledu těch, co se bojí, že Microsoft bude blacklistovat zavaděče nebo klíče, by tímto jiným jádrem mohla být zákeřná verze Windows. Systém chráněný secure bootem by tedy nakonec spustil nějaká špatná Windows, což je přesně tou situací, které má secure boot zabránit.

Pokud by se toto rozšířilo, tak různí lidé věří, že by Microsoft zakázal zavaděč, který byl v tomto útoku použit. Pokud by šlo o stejný zavaděč, jako by se používal pro start Linuxu, tak by nové systémy, stejně jako ty staré, kam se rozšířila aktualizace blacklistu, odmítly spustit Linux. Matthew Garret má z tohoto strach, a proto navrhl změny, které by vhodně nastaveným jádrům zakázaly kexec() a další věci, co by k obejití bylo možné použít.

To se řešilo na začátku září a tyto změny nebyly moc kontroverzní až na název capability, kterou Garrett pojmenoval jako (CAP_SECURE_FIRMWARE), a omezení kexec(). V půlce září poslal další dávku patchů, které byly skoro stejné, až na odstranění patche kexec() a přejmenování capability na CAP_COMPROMISE_KERNEL. K patchům uvedl, že pokud je někdo chce nasadit, tak zakáží kexec do doby, než bude začleněna podpora pro načítání podepsaných dat.

Asi tak na měsíc zavládlo ticho a pak se rozjelo rozsáhlé vlákno. Dotaz od Jiřího Kosiny o načítání firmwaru do „bezpečného“ jádra vedl k debatě o modelu rizik, který je pokryt Garretovým patchem. Ačkoliv Garrett souhlasil, že načítání firmwaru by mělo být řešeno přes podpisy, nekladl tomu velkou váhu. Automatizovaný útok za použití upraveného firmwaru by značně závisel na použitém hardwaru, vyžadoval by zpětné inženýrství a ve výsledku bychom z nich asi měli prospěch.

Jak James Bottomley upozornil, tu vždy budou chyby v jádře, které umožní obejití těchto omezení (např. když si root přečte podpisový klíč pro hibernaci nebo přepne bit dané capability):

[...] útok lokálně zvyšující práva obvykle využívá nějaké chyby (typicky buffer overflow), která spustí libovolný kód v kontextu jádra. V tomto případě může být stejný typ útoku použit ke kompromitaci jakéhokoliv jaderného ochranného mechanismu včetně vypnutí secure boot a přečtění jaderného soukromého podpisového klíče.

[...] Jde mi o to, že vzhledem k tomu, že většina exploitů dokáže spustit v jádře libovolný kód, tak nemá moc smysl uvažovat o podobných věcech jako o něčem, co zabrání útoku. Měli bychom se zaměřit na debatu o tom, proč chcete v prostředí secure boot zakázat legitimnímu lokálnímu rootovi zapisovat na oddíl pro hibernaci.

Jaderné exploity, ze kterých mají Garrett a další obavy, asi nikdo řešit nechce, alespoň co se secure boot týče. Kosina řekl:

Já to chápu tak, že nám nejde o ochranu před tím, aby root zneužíval chyby v jádře. Snažíme se zabránit tomu, aby root zasahoval do kódu a dat jádra přes standardní prostředky (/dev/mem, ioperm, přeprogramování zařízení, aby použila DMA na libovolná umístění, obnovení z obrazu hibernace, se kterým si pohrál, apod.).

Není ale jisté, proč by Microsoft rozlišoval mezi exploitem a regulérními jadernými službami, když by se rozhodoval blacklistovat. U distribucí, které šíří podepsaná jádra, je ale takto možné značně snížit riziko útoku.

Eric Paris podrobně popsal útok, jenž nainstaluje upravené linuxové prostředí (s legitimně podepsaným zavaděčem a jádrem), které se uspí poté, co připraví hibernační obraz Windows s trojanem. Uživatel by musel probudit systém dvakrát, ale nakonec by měl malware na systému se secure boot.

Bottomleymu a ostatním ale značně vadí představa „nedůvěryhodného roota“. V úpravách jádra pro bezpečný boot jde hlavně o omezení roota, aby nemohl v bootovacím prostředí dělat trvalé změny. Garrettem navržené patche odstraňují mnoho děr, pomocí kterých by root takové změny mohl udělat, ale lidé argumentují, že to nebude stačit. Alan Cox:

I s těmito všemi patchi mohu jako root nadále snadno převzít kontrolu nad strojem a současně jsi zakázal uspávání na disk, kexec a spoustu dalších užitečných věcí. Abys systém skutečně uzamknul, musel bys toho udělat mnohem víc.

Další možný způsob, jak by Linux mohl být použit k útoku proti Windows (právě tehdy by se asi klíče dostaly na blacklist), by bylo změnit chování zavaděče Linuxu. Bottomley navrhl, že ověření přítomnosti uživatele při prvním spuštění zavaděče, což se dá zjistit podle toho, že databáze klíčů UEFI a databáze „klíčů vlastníka stroje“ nebudou obsahovat ty správné klíče, rozsah problému omezí. Garrett upozornil na to, že předzavaděč toto nemá dělat, protože i při prvním bootu musí být schopen se spustit v nepřítomnosti uživatele. Bottomleymu to ale vadí:

[...] já ti říkám to, že umožněním automatického počátečního bootu způsobuješ problém, který může skončit útokem na Windows. Mohl bys snadno ověřit přítomnost uživatele při prvním bootu, což by tomu zamezilo. Místo toho ale řešíme všechno tohleto.

Garrett ale vidí automatický první boot jako naprostou nezbytnost, hlavně pro ty, kteří se snaží o automatizovanou instalaci. Ostatní s tím zase nesouhlasí a debata tak stále pokračuje. Hodí se říct, že předzavaděč, který Bottomley vydal, při prvním bootu ověřuje přítomnost uživatele (a nejen tehdy, dále pak při změnách v nastavení secure boot).

Hledání všech cest, jakými by „nedůvěryhodný root“ mohl zasahovat do prostředí secure boot, se zdá být tak trochu nekonečné. Kromě toho budou i všechny budoucí funkce muset být prověřovány, zda nemusejí být v závislosti na CAP_COMPROMISE_KERNEL zakázány.

Nedůvěra v roota je něco pro jaderné vývojáře (a uživatele) dosti nezvyklého. Asi si můžeme představit, že budou všechna problémová místa nakonec vystopována, ale bude to stát hodně úsilí. Jestli si to zaslouží funkce, která je značně (i když ne úplně) užitečná jen pro ochranu Windows, toť otázka. Na druhou stranu, nemoci snadno bootovat Linux na x86 hardwaru jen kvůli blacklistu klíče by bylo také problematické. Budeme si ještě muset počkat, jak to celé dopadne.

Diskuse k tomuto článku

[Mrkva]

Snažíme se zabránit tomu, aby root zasahoval do kódu a dat jádra přes standardní prostředky (/dev/mem, ioperm, přeprogramování zařízení, aby použila DMA na libovolná umístění, obnovení z obrazu hibernace, se kterým si pohrál, apod.).

A když si root natáhne vlastní modul, tak co? :)

[Conscript89]

Pokud podpis modulu nebude matchovat spravnym klicum, zavedeni modulu selze. Toto uz je vyreseno.

[Mrkva]

Ehm... A admin nebude moci podepisovat vlastní moduly?

[Michal Vyskočil]

Ne, dokud do UEFI proměnné nepřidá vlastní klíč. Distributoři jej pravděpodobně zveřejňovat nebudou

[Jakub Lucký]

takže ti, co chtějí použít Nvidii nebo Virtualbox se SB pravděpodobně ostrouhají?

Jupí...

[pc2005]

To bude v diskuzích legrace. Polovina z nich bude začínat stylem: Vypněte si secure boot .

[Petr Ježek]

Ta legrace je poněkud dětinská. Komu nedochází, že bezpečnostní opatření vyvinuté pro nebezpečné OS koliduje s bezpečnými OS právě proto, co činí bezpečné OS bezpečnými na rozdíl od nebezpečných OS, tak by se měl nad sebou dlouze zamyslet. Pojetí důvěryhodného roota není konzistentními zásahy bránící aktům "nedospělého roota" zevnitř OS oslabeno, naopak posíleno na rozdíl od externích vstupů do pre-boot sekvencí, jež by měly být neutrální k vlastnímu OS. Je symptomatické, jak se MS neustále snaží řešit své problémy na cizí účet.

[Michal Kubeček]

Nenatáhne.

[esparky]

Přijde mi to jako docela dobrá taktika jak prosadit EUFI...bez problémů necháme odpůrce podepsat několik zavaděčů, aby moc neotravovali a když pak budou zlobit, tak je jednoduše vypneme (blacklistem, popř se jejich klíč neobjeví v novém hw)...Vám to tak nepřijde?

[Bluebear]

Samozřejmě. Microsoft prostě dělá to, co umí nejlépe: škodí.

[Marián Kyral]

Tak roota osekáme co to půjde. ale co když si zkompiluje vlastní kernel? To se mu taky zakáže? Nehledě na to, že neosekaná verze jádra bude neustále k dispozici v gitu. Co mi zabrání si jádro zkompilovat na míru a pak jej zavést? Nějaká možnost podepsat si vlastní jádro být musí. To bychom pak odstřihli distribuce typu LFS a Gentoo. Jsem zvědav, jak se tohle zabezpečení podaří nacpat do Gentoo handbooku

Co je vlastně cílem celé téhle šílenosti?

[Conscript89]

Vlastni kernel a vlastni moduly neni problem s UEFI secure boot. Jenom si pak to vsechno musis podepsat a svuj klic dat do UEFI pameti klicu (ted nevim do ktere sekce presne, ale vim ze tam misto na uzivatelske klice je).

[Conscript89]

Jo a zakazany je to pak na urovni zavadece. Pokud nemas podepsany, nebo mas podepsany spatne, zavadec odmitne takove jadro zavest.

[Michal Kubeček]

Cílem je, aby ten, kdo bude chtít používat Linux s distribučním jádrem na stroji s povoleným UEFI "secure bootem" (např. kvůli dual bootu s Windows), to tak mohl mít bez nutnosti lézt do setupu a buď si tam přidávat vlastní klíč nebo střídavě "secure boot" vypínat a zapínat.

Kdo si bude chtít překládat vlastní jádro, ten si tam stejně přidá vlastní klíč nebo "secure boot" rovnou vypne, takže toho se to netýká. Speciální případ je ten, kdo sice chce bootovat vlastní jádro, ale bude chtít secure boot a secure mode využít k tomu, aby měl jistotu, že se bootuje opravdu právě jen to jeho jádro - ale to IMHO nebude až tak časté.

[Grunt]

Cílem je…

Já si myslím, že skutečným cílem je opravdu zabezpečit aby žádný jiný (ani svobodný) operační systém nemohl natáhnout podvrhnuté Windowsí jádro. Protože přesně tak se to dělalo u cracknutých Windů Vista. Nebudu to popisovat celé, ale jednou ze součástí byl otevřený GRUB4DOS celé v tandemu ve kterém se natáhne jádro, které si myslí že je pořád na původní HW konfigraci. A to se právě dle mého názoru snaží Microsoft zastavit. Aby se nedalo natáhnout žádné jiné jádro než to oficiálně na OEM PC předinstalované a aby zároveň se nedal natáhnout žádný jiný systém, který by takové věci jako natahování jiných jader s uživatelem danými parametry dovolil (nazývat jádro u kterého je funkční kexec jakožto „kompromitované“ je směšné). Je tady prostě vidět ten tlak na jaderné vývojáře k implementování této funkčnosti, protože mi nevykládejte že o takové cipoviny se aktivně snaží sami. Budoucnost potom bude oficiální předinstalovaný Windows a z oficiálních distribučních zdrojů nainstalované GNU distribuce s „nekompromitovaným“ jádrem a z pohledu systému Windows zase zpětná kontrola klíčů v UEFI zavaděči (pro případ, že by si někdo udělal vlastní klíč, nahrál jádro co dovoluje natahovat jiné jádra, protože to je cesta je cracku). Na to bych klidně vsadil svoje boty. A navíc se tak dokonale sváže operační systémem s daným HW a neoddělitelnost nebude jen právní (pomocí smluv), ale i technická.

[Michal Kubeček]

Jen bych upřesnil, že jsem ve svém příspěvku měl na mysli cíl vývojářů pracujících na podpoře "secure bootu" v Linuxu. O cíli Microsoftu se asi nemá smysl bavit, ten je jasný každému, kdo je trochu v obraze.

[mmk]

Připadá mi, že se vynakládá příliš energie jak žít se secure boot. Hlavní energie by se měla vynaložit na zničení secure boot.

Účelem secure boot není to co o něm tvrdí jeho zastánci. Účelem je, že MS využije své dominance v x86 k vytváření bariér pro ostatní konkurenty a vyšlape si cestičku pro spolehlivější DRM. Oboje ve výsledku směřuje k vytváření vysokých zdí pro všechny, kdo používají nebo chtějí vyzkoušet jiný OS než je ten MS. Navíc bude možné prohlašovat, že ten Linux není ani bezpečný, protože neumí pořádně secure boot.

Secure boot je zlo!

[Salamek]

+1

[Tutor]

+1

[Ray]

(+1) << 32 :)

[michi]

Overflow?

[pc2005]

32bit je šmejďárna . (a nebo to shiftuje do carry )

[R]

Presne tak.

A s Windows 9 pride poziadavka, aby vyrobcovia HW neumoznovali ziadnu manipulaciu s klucmi ani vypnutie secure bootu.

[Luboš Doležel (Doli)]

Myslím si, že tehdy by se EU ozvala.

[Scarabeus IV]

Nikdo se neozval, kdyz se tohle zavedlo na ARMu, protoze tam MS jeste nema monopol.
Takze cekam neco jako "Podivejte jak krasne nam to na tom armu funguje, jen to sjednotime".

[Luboš Doležel (Doli)]

Nikdo se neozval, kdyz se tohle zavedlo na ARMu, protoze tam MS jeste nema monopol.

Tak, tam není důvod to hrotit...

Takze cekam neco jako "Podivejte jak krasne nam to na tom armu funguje, jen to sjednotime".

Nemyslím si, že by EU na něco takového skočila.

[heh]

Na ARM je Microsoft bezvýznamný hráč a vzhledem ke "kvalitě" jeho softwaru to tak i zůstane. Jediné z čeho těží je zpětná kompatibilita aplikací a ta na ARM padá.

[Trident]

Are u sure? Tech kravin na windows ce/embedded neni v prumyslu zrovna malo.

[robo]

Ale EU sa neozvala. Na x86 je to ok. Ak je to len ako option v biose tak to je podla mna v poriadku. Problem ale vidim v tom ze na inych ako x86 architekturach Microsoft vyzaduje aby sa to nedalo vypnut. Resp oni to nevyzaduju. Ale na takom HW potom bude problem s Win8. A proti tomu sa EU neozvala.

[Luboš Doležel (Doli)]

A proti tomu sa EU neozvala.

Protože Win8 na ARM HW nikoho nezajímá... stejný propadák jako jejich Windows Phone.

Ten se taky chytil jen u pár mých známých Win programátorů/integrátorů/whatever, co opěvují každý exkrement, co z té firmy vyleze. Když to člověk vidí, tak si říká, jestli nejedou na fetu, že ztratili zbytek soudnosti.

[heh]

spíše je to dobře živí

[Luboš Doležel (Doli)]

Bingo.

[Petr Ježek]

Jen druh fetu.

[Grunt]

A s Windows 9 pride poziadavka, aby vyrobcovia HW neumoznovali ziadnu manipulaciu s klucmi ani vypnutie secure bootu.

To ne, ale spíš si IMHO Microsoft najde způsob jak kontrolovat seznam klíčů v UEFI a když tam bude něco navíc místo jejich oficiálního seznamu, tak počítač bude vyhlášen za kompromitovaný a jádro systému Widnows začne hrát Zagorku. Takže žádný dualboot s custom-made jádrama. Úžasná budoucnost.

[heh]

On ještě někdo provozuje Widle v dual-bootu?

Pustit tenhle Malware přímo k hardwaru není optimální, od čeho máme virtualizaci. S funkčním IOMMU není problém Widlím přiřadit i dedikovaný kus hardwaru jako grafická karta nebo řadič.

[Trident]

Typicky hatewin hipie vyblitek. Uz jsi nekdy zkousel narocnejsi 3d hru ve virtualu? Realtime veci? Zvukove editory? Na pc stejne zadna hw virtualizace ve skutecnosti neni. Ta je Jen na hiendovem zeleze(nonx86) a mainframech. Iommu je jen berlicka.

[trekker.dk]

Máš tam chybu. Za "Typicky hatewin hipie vyblitek" měla místo tečky být dvojtečka

[Jiří J.]

Já se hlavně divím, že se to dostalo do současné situace. Vždyť přístup k tomu, co půjde bootovat, má jedna (komerční) firma, které ostatní musí platit za podpis -> je to jasný monopol. Co víc je potřeba k tomu, aby zasáhly příslušné orgány? Nasazení tohoto monopolu do běžné praxe?

[Conscript89]

No, podepsat ti to muze kdokoliv, zalezi na HW vendorech, ktere klice daji do systemu, ktere prodavaji. Mit podepsany klic stejnym zpusobem jako ma MS je jednodussi a kazdy vendor bude jejich klice davat do systemu co prodava (teda s vyjimkou Ubuntu HW).

[pc2005]

+1

[Petr Tomášek]

Tak si říkám, že by bylo dobrý, kdyby si člověk mohl na vlastní desce dělat s klíčí v UEFI secure bootu, co chce. Já bych si hned vytvořil klíče vlastní pro vlastní jádro a hlavně bych okamžitě smazal klíč MS, aby mi ten počítač nemohl nikdo zavirovat

[Conscript89]

Presne tak nejak to budes moct udelat. I kdyz s tim mazanim si nejsem mo jisty, ono je to se strukturou klicu komplikovanejsi, nekde k tomu budou urcite materialy (KEK, a takovy... ).

[Grunt]

nějaká špatná Windows

To jsou prosím jaká Windows?

[Luboš Doležel (Doli)]

Já bych řekl, že všechna; pro účely článku to ale jsou veškerá Windows, která by se nelíbila Microsoftu, tj. cracknutá, zavirovaná...

[pet]

Prostě veškerá...

[little.owl]

To ja mam spise obavy, aby pres zavsivene Windows nenapadli Linux! A proto potrebuji poradne zabezpeceny Linux ....

[Sten]

Na to přece stačí LUKS, ne?

[little.owl]

Bootovat pres [i podepsany] Grub2? To jeste tak ....

[Petr Ježek]

Takže je to bez problémů, pouze se někomu nechce?

[little.owl]

Neni a zatim to nejde.

[Jendа]

Ne.

[LL]

Stejne nekdo casem prolomi kodovani a bude podepisovat zavirovana windows originalnim klicem Microsoftu. Oni tenhle klic nebudou moc vypnout, protoze by prestaly windows bootovat.

[mankind_boost]

Windows update často mění jádro + oni si můžou přidat/odstranit klíče - tudy cesta nevede.

[Atom321]

A 21.12.2021 se aktivuje zákeřný virus, který microsoftí klíče na všech napadených strojích odstraní. Na záložní konec světa je zaděláno .

[heh]

ale to by znamenalo ze Widle nepujdou ani nainstalovat, protoze instalacni media budou mit porad puvodni podpis

[loki]

Doufam, ze vyrobci x86 hw zachovaji moznost tuto novou uzasnou vlastnost vypnout.

[mankind_boost]

U Windows RT (ARM) je zakázáno umožnit uživateli vypnout UEFI nebo měnit jeho klíče. U Windows 8 (x86/x86_64) je to povoleno.

Dá se čekat, že u Win 9 (až si všichni zvyknou) to nepude ani na x86.

[Michal Kubeček]

U Windows 8 (x86/x86_64) je to povoleno.

Přesněji: je povinné to umožnit.

[heh]

U Windows 8 (x86/x86_64) je to povoleno.

Přesněji: je povinné to umožnit.

Přesněji řečeno je to dobrovolné. Tato podmínka se nachází v certifikaci pro Windows, nikdo k tomu vyrobce nijak nenuti

[Michal Kubeček]

Teoreticky. V praxi se těžko bude výrobce HW patlat s implementací "secure bootu" a předinstalací MS klíčů z jiného důvodu než kvůli právu dát si na krabici okénkové logo.

[jurasn]

Škoda jen, že kvůli Win musíme kriplit Linux v jeho samotné podstatě. Jestli to takto půjde dál, tak se brzo dočkáme situace, že root bude mít stejné pravomoce jako Administrator ve win, který ani nemůže udělat chmod na systémových souborech.

[Bluebear]

Ale pořád budeme mít zdrojové kódy jádra, takže si to každý bude moci upravit podle svého.

[Ray]

I to se da zmenit, patricne operace se proste potavi mimo zakon. Ve jmenu ochrany Velkeho Obsahu, boje proti terorismu a ochrany proti detskemu pornu, se da shcalit takrka cokoliv :) Nebo spis :(

[Bluebear]

I to se da zmenit, patricne operace se proste potavi mimo zakon.

To je pravda, ale v této fázi IMO nemá význam se tímto zabývat (ještě ne), protože zákonem může být zakázáno cokoliv, celý Linux, programování jako celek, počítače jako celek (Taliban například na svých územích zakazuje veškerou hudbu)... to bychom zešíleli.

[Antikapitalista]

No to se pleteš, protože stejné to bylo i v případě softwarových patentů apod.; kdybychom nebyli popisovali i apokalyptické vize a nebyli dělali u toho takový kravál, tak by to možná klidně v tichosti prošlo...

A ano, klidně mohou zakázat „takové programování, které má za cíl obejít ochranu Obsahu“, pak „takové programování, které může být zneužito k prolomení ochrany Obsahu“, dá se to do trestních zákoníků... a bude vymalováno. Programování by bylo i nadále dovoleno, ovšem jakmile bys udělal něco, co by „Strážci Obsahu“ považovali za „závadné“, pak bys měl na krku trestní stíhání.

Nebylo by to nic neobvyklého, neboť již dneska je běžně trestné používani nástrojů pro obejití „Ochrany“, jejich dovoz a šíření. Britský režim rovněž trestá neposkytnutí dešifrovacího klíče (což je vlastně totéž, jako kdyby vraha chtěli potrestat za to, že jim neprozradí, kam zahodil nůž), čili na nějaká lidská práva se v kapitalizmu můžete akorát tak vys..., ehm, vysmrkat.

[Suchý čert]

Ale k čemu to bude, když to pak nepůjde spustit?

[pc2005]

Další možný způsob, jak by Linux mohl být použit k útoku proti Windows (právě tehdy by se asi klíče dostaly na blacklist), by bylo změnit chování zavaděče Linuxu. Bottomley navrhl, že ověření přítomnosti uživatele při prvním spuštění zavaděče, což se dá zjistit podle toho, že databáze klíčů UEFI a databáze „klíčů vlastníka stroje“ nebudou obsahovat ty správné klíče, rozsah problému omezí. Garrett upozornil na to, že předzavaděč toto nemá dělat, protože i při prvním bootu musí být schopen se spustit v nepřítomnosti uživatele. Bottomleymu to ale vadí:

Tohle všechno jen kvůli Windows? Vývojáři zřejmě nemaj nic na práci .

[trekker.dk]

Vývojáři zřejmě nemaj nic na práci

No oni by pravděpodobně měli na práci něco užitečnějšího, co by dělali radši. Jenže pracují pro někoho a aby dostávali peníze, musí dělat to, co ten někdo chce.

[Petr Ježek]

Nemyslím, že by se nenašel vývojář, který by za peníze někoho udělal pro něj práci tak, aby to neblokovalo použití obdobné práce jiných. Pár takových z trochu jiného oboru jsem poznal i v Dánsku...

[Sleep_Walker]

Dokud bude moznost Secure Boot vypnout v BIOSu, tak to jako ochrana nebude fungovat, protoze software pujde vzdy upravit, aby se tvaril spokojene. Az nez to bude povinne, bude x86 mrtve a na ARMu Linux proste fungovat bude :)

Reknete svym kamaradum na facebooku, ze jim se secure bootem kradene widle nepojedou, tak at si daji pri nakupu pozor. A "lajkujte" jak o zivot.

[multi]

Bude sranda, az si clovek notebook se securebootem posle na opravu. V oprave notas budou zkouset s windouzama ...... a az notas vrati, tak diky blacklistu uz linux nenabooduje. Predpokladam, ze mu pak asi neuznaji, ze mu pri reklamaci ten notebook rozbili :D

[Antikapitalista]

Nějak se v tom ztrácím – k čemu to vlastně všechno je?!

Já bych byl klidně za to, aby to Microsoft klidně zakázal...! Buďto by pak (v pořadí dle pravděpodobnosti):

1. udělal výjimku pro evropský trh, anebo

2. dostal od EK mastnou pokutu a zákaz toho, co zakázal (tedy zákaz prodejů těch „zabezpečených“ věcí), anebo

3. konečně by tu vypukla revoluce, která by smetla celý kapitalistický systém i s jeho „duševní posedlostí“.

Čili... Microsoft se chystá odrbávat svět (ve spojení s výrobci zařízení) naivní jaderní ňoumové mu k tomu coby užiteční idioti ještě dláždí cestu!!

[Antikapitalista]

Mimochodem, tohle je v podstatě stejné, jako kdyby si výrobce kuchyňského náčiní najednou usmyslel, že je nutné „zabezpečit“ nůž tak, aby ho nešlo zneužík k řezání...

[Antikapitalista]

Oops, tak beru to zpět... Přečetl jsem si související článek Another approach to UEFI secure boot a dle něj to vypadá, že Matthew Garrett je vývojář jádra Windowsu – dle toho, co mu zjevně nejvíc leží na srdci...