Jaderné noviny 217

29. 5. 2003 | Leoš Literák | Jaderné noviny | 3816×

Digital Rights Management v jádře? Přepis souborového systému HFS+. Hluboká a temná zákoutí bootu. Podpora pro Virtual Redundancy Router Protocol.

Do konference přišlo celkem 3112 emailů, nejvíce jich poslali Alan Cox, Jens Axboe, William Lee Irwin III.

Digital Rights Management v jádře, 299 e-mailů

Linus Torvalds napsal:

Dobře, nejde to udělat elegantně, takže se o to nebudu ani pokoušet. Jdu usadit svou zadnici kvůli skutečně velmi impozantní plamenné diskusi a mé azbestové spodky jsou nasazeny a mimořádně nepohodlné.

Chci jasně říci, že Linux s DRM nemá vůbec problém.

Tak, řekl jsem to. Už jsem ze záchodu pryč. Takže začněte...

Už jsem o tom soukromě diskutoval s různými lidmi a zjistil jsem, že spousta lidí chce používat kernel tak, aby neumožňoval DRM. Ať už skrze politické rozhodnutí nebo rozšířením GPL.

Svým způsobem se diskuse podobají rok starým diskusím o softwarových patentech týkajících se GPL-NG: "nelíbí se nám to, takže raději nějak změňme licenci, aby to nešlo". A jako u problému se softwarovými patenty, osobně DRM nemám rád, ale nakonec se cítím stejně: Jsem "Oppenheimer" a odmítám hrát politické hry s Linuxem a myslím si, že můžete používat Linux pro co chcete - což rozhodně obsahuje i věci, které bych osobně neschválil.

GPL po vás požaduje zdroják od kernelu, ale neomezuje vás, co můžete s kernelem dělat. V podstatě je to další příklad toho, proč mě RMS [Richard M. Stallman] nazývá "jen inženýr" a myslí si, že nemám žádné ideály. (Osobně to cítím jako přednost - snaha vytvořit ze světa trochu lepší místo bez vnucování svých morálních hodnot ostatním. Dělejte si, co chcete, jsem jen inženýr, který chce udělat nejlepší možný operační systém.)

Krátce, je úplně v pořádku podepsat obraz kernelu, nepřímo to dělám již dnes, neboť kernel.org podepisuje tar balíčky, které tam nahraju, aby si lidé mohli ověřit, že přišly touto cestou. Udělat to samé na binárce, v tom není rozdíl: podepsání binárky je korektní způsob ukázání světu, že jste to vy, kdo za ní stojí a že vy jí věříte. A protože si dovedu představit sebe podepisujícího binárky, nemyslím, že bych v tom mohl někomu jinému bránit.

Další částí diskuse o DRM je fakt, že podepisování je jen prvním krokem: jednat na základě toho, zda je binárka podepsána či nikoliv (například odmítnutím spustit ji nebo dát ji tajný klíč) je také požadováno. Ale protože podpis je zbytečný, dokud jej pro něco nepoužíváte a protože rozhodnutí, jak používat podpis, jasně leží mimo dosah kernelu (a proto není odvozenou [derived] prací), musím přesvědčit sebe, že je nejen v pořádku jednat na základě znalosti, zda je kernel podepsaný či ne, ale že je to mimo rozsah toho, o čem GPL mluví a proto je irelevantní vůči licenci.

Tak a je to. Chtěl jsem to vynést ven, protože vím, že jsou zde lidé, kteří si myslí, že podepsané binárky jsou podvracením (či perverzí) GPL a chtěl jsem zajistit, že lidé nebudou žít v nepochopení, že to nejde udělat. Myslím, že je zde spousta dobrých důvodů, proč podepisovat (a verifikovat) obrazy jádra a přestože některé použití podpisů jsou hnusné, nevidím žádný čistý způsob, jak rozlišit dobré a špatné podepisovače [signers].

Komentáře? Rád bych viděl nějakou skutečnou diskusi ohledně tohoto problému, ale nakonec jsem osobně přesvědčen, že to musíme povolit.

Mimochodem, jedna věc, která jasně není povolena GPL, je skrývání soukromých klíčů v binárce. Můžete podepsat binárku jako výsledek build procesu, ale nemůžete vytvořit binárku, která si je vědoma určitých klíčů bez toho, aby ty klíče byly veřejné - protože tyto klíče by zřejmě musely být součástí kernelu samotného. Takže nepleťte tyto dvě věci dohromady: externí klíč aplikovaný na kernel (OK) a začlenění klíče do kernelu (také to jde, ale GPL požaduje, aby takový klíč byl zveřejněn jako "zdrojový kód").

Greg KH odpověděl, že zná spoustu lidí, kteří by takhle chtěli (a dělají to) používat Linux a že rád vidí tak explicitní tvrzení, že je to přijatelné. To vyjasní tenhle problém.

Andre Hedrick napsal delší dopis na podporu Linuse, ve kterém ukázal, že hardware již podporu DRM obsahuje a že se musíme smířit s tím, že DRM již zde je. Jediným řešením je ovládat jej, proto Andre s pomocí několik další členů komise NCITS T13 za pomoci Microsoftu zařídil, že konečný uživatel může tuto sadu vlastností vypnout.

Andre dále dodal, že digitální podepisování se dá použít pro ochranu embedded nebo distribučních prostředí. DRM je totiž obousečné a na to nemáme zapomenout. My jako Open Source komunita můžeme používat DRM jako prostředek pro povolení či odmítnutí funkčnosti. Nyní podle něj nastal čas, jak ovládat tento nástroj. Podobně jako u ohně, ovládněte DRM/CPRM a můžete z toho profitovat. Nechte mu volnost a shoříte.

Linus reagoval na obousečnost DRM:

Toto je nejdůležitější část pro zapamatování.

Bezpečnost je meč o dvou ostřích. Může být použita pro vás a může být použita proti vám.

Technologie samotná je vlastně neutrální a osobně jsem celkem optimistický, že zvláště v Open Source prostředí najdeme největší snahu používat bezpečnost ve prospěch zákazníka. Bezpečnost pro uživatele, ne pro utiskování uživatele.

Jinde William Lee Irwin III odpověděl Linusovi, že nemá zájem o řešení morálních problémů, ale zdá se mu, že DRM je jen transparentní komplot, jak zabránit bootování cizího kódu na různých strojích. Linus reagoval:

Buďme čestní - pro některé lidi to je přesný účel DRM. Žádné když, možná nebo ale.

Faktem je, že dokud vyrábíte hardware, můžete řídit, co na něm poběží.

GPL vyžaduje, abyste zpřístupnili software, ale nepožaduje, aby byl vyroben hardware tak, abys mohl vždy upgradovat. Můžete zapsat binárku kernelu do ROM a prodat ji se základní deskou. To je v pořádku a vždycky bylo. Dokud dáte k dispozici zdrojové kódu k softwaru, není zde nic, co by říkalo, že hardware musí být vytvořen tak, aby bylo snadné (či dokonce vůbec možné) změnit jeho binárku.

A jsou zde projekty pro "Open Hardware" (jako opencores.org atd.) a může se stát, že budou velmi důležité. Ale Linux je o Open Source, ale ne o hardware a hardwará otevřenost nikdy nebyla podmínkou pro běh Linuxu.

Přepis souborového systému HFS+, 11 e-mailů

Roman Zippel hrdě ohlásil, že dokončil kompletně novou verzi ovladače souborového systému HFS+. Tuto práci umožnila firma Ardis Technologies. Ovladač je založen na originálním ovladači Brada Boyera ( http://sf.net/projects/linux-hfsplus).

Nový ovladač podporuje plný přístup pro čtení i zápis. Výkon výrazně vzrostl, b-stromy jsou udržovány v keši stránek spolu s hash tabulkou pro urychlení přístupu. Roman dále přidal podporu hard linků. Fork zdrojů [resource fork] je dostupný skrze <file>/rsrc.

Ovladač můžete stáhnout z http://www.ardistech.com/hfsplus/. README popisuje, jak ovladač zkompilovat..

Jeffrey Baker napsal, že jde o výrazný pokrok pro uživatele iPod a Maců, Miles Lane se kromě radostného výkřiku zeptal, kdy bude ovladač začleněn do jádra 2.4 či 2.5.

Brad Boyer napsal Romanovi, že

Pokud ti to nevadí, začnu začleňovat tvé změny do CVS stromu na SourceForge. Předpokládám, že jde o GPL kód, neboť jsi začal z mých originálních záplat... Počkám na tvou odpověď, neboť se jedná o dost velkou změnu.

Roman odpověděl stručně:

Samozřejmě, že je.

Hluboká a temná zákoutí bootu, 37 e-mailů

Andi Kleen napsal:

Po intenzivní diskusi různých expertů v konferenci discuss@x86-64.org jsme zjistili, že správná adresa [vector] pro restartování 286+ CPU je f000:fff0, nikoliv ffff:0000. Oba se zdají fungovat na moderních systémech, nicméně první je správný.

Viz vlákna "DPMI on AMD64" a "Warm reboot for x86-64 linux" na adrese http://www.x86-64.org/mailing_lists/list?listname=discuss&listnum=0.

Jamie Lokier odpověděl:

Máš pravdu. To je, co 286 dělá, když přijme RESET signál.

Je to zajímavé, neboť jsem to byl já, kdo použil to ffff:0000 a to jsem se tehdy přečetl z knihy Phoenix BIOS book.

Právě jsem googloval a našel příklady dosovských programů používajících obě adresy.

Jos Hulzink dodal:

16-bajtový kód je příliš malý a obvykle obsahuje ten DLOUHÝ skok do užitečného adresového prostoru.

Když použijeme adresu f000:fff0, přežijeme BIOSy, které používají relativní skoky s negativními offsety nebo nepřímé krátké skoky.

Když je použita adresa ffff:0000 a kódový segment [CS] obsahuje jen 16 bajtů, nemůžete ani myslet na krátké skoky s negativními offsety. Kód v tak rané fázi totiž dostupný jen ke čtení, sebemodifikující kód (který používá absolutní adresy) může být také vyloučen.

Dobře, 386 a novější procesory potřebují daleký skok pro odemknutí A20-A31, takže myslím, že je bezpečné předpokládat, že všechny BOISy udělají daleký skok, jakmile to bude možné, což znamená, že je jedno, která adresa je použita.

Nicméně kvůli špatně se chovajícím BIOSům hlasuji pro adresu f000:fff0, dokud mi někdo neukáže papír, který říká, že je to špatné.

Do diskuse se pak zapojil i Linus Torvalds a vývojáři se trumfovali, kdo má pravdu.

Podpora pro Virtual Redundancy Router Protocol, 3 e-maily

Chien-Lung Wu se zeptal, zda Linux podporuje VRRP (Virtual Redundency Router protocol). Gianni Tedesco zaslal odkaz na Keepalived, and Maciej Soltysiak napsal:

Přečti si o vrrpd http://lartc.org/howto/lartc.other.html. Také vyzkoušej http://sourceforge.net/projects/svrrpd/.

 

Související články

Jaderné noviny 216
Jaderné noviny 215
Jaderné noviny 214

Odkazy a zdroje

Kernel Traffic 217

       

Komentáře