Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Současné vývojové jádro je 2.6.36-rc5 vydané 20. září. Nic na něm nevyniká. Možná kromě toho, že Al pochopitelně koukal na cesty sigreturn a nacházel tam chyby a Dan Rosenberg nacházel místa, kde do uživatelského prostoru kopírujeme struktury, aniž bychom je kompletně inicializovali, čímž uniká obsah jaderného zásobníku. A měli jsme tu otravnou chybu 32-bit kompatibility v syscallech na x86-64, kterou bylo potřeba opravit podruhé. Zkrácený changelog vizte v oznámení, všechny detaily v kompletním changelogu.
Stabilní aktualizace: 20. září byly vydány aktualizace 2.6.27.54, 2.6.32.22 a 2.6.35.5. Všechny obsahují dlouhý seznam důležitých oprav.
-- Ingo Molnár
-- Chris Mason
Jon Masters oznámil, že bude opět vytvářet jaderné podcasty. Mým záměrem je vrátit se k pravidelné produkci, protože mi to pomáhá sledovat LKML - v nedávné době jsem měl dost času na to, abych udělal přípravu, ale už ne dost na to, abych napsal scénář a nahrál to. Nedělám to z žádného jiného důvodu, než abych se donutil sledovat LKML.
Oracle vydal tiskovou zprávu, ve které vyjmenovává přednosti svého nového jádra. Je založeno na společných snahách týmů techniků pro Linux, databáze, middleware a hardware. Unbreakable Enterprise Kernel je rychlý: více než o 75 procent vyšší výkon při OLTP než Red Hat Compatible Kernel; 200% zrychlení předávání Infiniband zpráv; o 137% rychlejší přístupy k diskům bez rotujících částí. Mnoho z těchto zrychlení může vznikat z toho, že se jako základ místo 2.6.18 používá 2.6.32, ale těžko říci s jistotou; zdrojové kódy tohoto jádra nejsou v době psaní tohoto článku k dispozici.
Tento krok je zajímavý v tom, že znovu zavádí konkurenci na úrovni jádra - což je něco, na co distributoři v nedávných letech příliš velký důraz nedávali. Také to demonstruje úmysl trochu se odklonit od RHEL, který Oracle používá jako základ své nabídky.
napsal Jake Edge, 22. září 2010
Justin P. Mattock se rozhodl, že udělá velký úklid: aktualizaci všech webových odkazů v komentářích zdrojových kódů jádra. Jak lze uhodnout, mnoho z těchto odkazů za těch posledních deset nebo více let vyhnilo, takže se Justin chce pokusit zaktualizovat jádro tak, aby ukazovalo na správné místo - pokud takové místo bude možné najít. Tato snaha vyústila v v monstrózní patch, který pokrývá všechny výskyty "http", které bylo možné najít.
Mnoho z nových odkazů nyní míří na archive.org, protože to je jediné místo, které Justin byl schopen dohledat. To ale vedlo na problém s formátováním. Přibyly totiž odkazy jako:
http://web.archive.org/web/*/http://staradomena/staryodkaz
Ty ukazují na všechny různé verze stránek, které stroj času zaznamenal. Jenže vložit „*/“ do komentáře v jazyce C není dobrý nápad, jak upozornil Matt Turner. Správné řešení je použít "%2A", což je HTML entita pro „*“. Archivní odkazy mají ale i větší problém.
Finn Thain řekl, že takové odkazy by bylo lepší nechat na pokoji, protože lidé by o archive.org již měli vědět; přidávat ke starému odkazu „archive.org“ nemá cenu. K tomu je navíc otázka, která verze uložené stránky je ta, na kterou se odkazoval původní komentář. Finn v podstatě říká, že užitečnější pravděpodobně budou webové stránky, které jsou udržovány a aktualizovány. Ti, kdo se chtějí podívat na stránky, které ze sítě vypadly, by měli vědět (nebo si zjistit), jak na to.
Justin nakonec rozdělil patch na dvě části, jedna aktualizuje staré odkazy, druhá přidává odkazy na archive.org pro weby, které se ztratily. Čeká na další zpětnou vazbu ohledně toho, jestli zahrnout odkazy do archivu nebo ne.
Přinejmenším zatím není jisté, jestli budou tyto změny akceptovány. V jistém smyslu je to jenom ruch, který pravděpodobně bude následován dalším ruchem, protože vyhnívání odkazů je věčný problém webu. Pro vývojáře je dost možná frustrující narážet na nefunkční odkazy v kódu jádra, ale stojí to za nekončící - doufejme, že ne moc časté - proudy patchů? I když se nepochybně mohou objevit problémy s autorskými právy, s logistikou i jiné, i tak by bylo rozhodně lepší, kdyby dané dokumenty bylo možné trvale uložit někam na kernel.org.
napsal Jonathan Corbet, 20. září 2010
Odstraňování velkého jaderného zámku [Big Kernel Lock, BKL] je nepřetržitá a několikaletá snaha, o které se tu již několikrát psalo. BKL má několik podivných a unikátních vlastností, kvůli kterým je jeho odstranění z různých jaderných subsystémů záludnější, než by jeden čekal. Nicméně díky práci Arnda Bergmanna se možná blížíme okamžiku, kdy bude možné pro většinu uživatelů přeložit jádro 2.6.37 bez BKL. Zbývá zde nicméně jedna významná překážka, kterou musíme překonat.
Arndew má v současnosti ve stromě linux-next obrovské množství patchů. Mnoho z nich je výsledkem nudné (ale záludné) práce, která spočívala v podívání se na specifický subsystém, zjištění, který zámek ve skutečnosti potřebuje, a následnou záměnou volání lock_kernel() na něco lokálnějšího. V mnoha případech lze zamykání pomocí BKL jednoduše odstranit, protože se ukazuje, že kód zamykání nepotřebuje. Velké pozornosti se v 2.6.37 dostalo odstranění BKL z mnoha souborových systémů - to je úloha, která vyžadovala překopání poměrně starého kódu. Například Amiga FFS pravděpodobně v poslední době příliš udržován nebyl a nezdá se pravděpodobné, že by měl mnoho uživatelů.
Patch pro 2.6.37 s největším záběrem se týká funkce llseek(), kterou lze nalézt ve struct file_operations. Tato funkce umožňuje ovladači nebo souborovému systému implementovat systémové volání lseek() a změnit tak pozici popisovače v daném souboru. Narozdíl od většiny funkcí ve file_operations má llseek() výchozí implementaci, která jednoduše mění pohled jádra na pozici popisovače bez zapojení kódu níže – změna přirozeně probíhá s držením BKL. Tato implicitní výchozí implementace llseek() možná zjednodušila život několika vývojářům, ale ztěžuje odstranění BKL: změna implementace by mohla ovlivnit jakýkoliv kód se strukturou file_operations, nejenom moduly, které implementují operaci llseek().
Aby to bylo ještě těžší, většina těchto implicitních implementací llseek() není vůbec zapotřebí - většina ovladačů zařízení nemá žádný koncept „pozice v souboru“ a nevěnuje pozornost tomu, o čem si jádro myslí, že by tato pozice mohla být. V takových situacích je lákavé změnit kód na implementaci s explicitním „není možné měnit pozici“, která by lépe reflektovala to, co se skutečně děje. Problém je v tom, že nějaká aplikace někde může volat lseek() na zařízení a mohlo by ji naštvat, že se jí vrátilo ESPIPE. Jinými slovy může být úspěšné–ale–ignorované volání lseek() pro nějaké zařízení součástí ABI pro uživatelský prostor. Je tedy potřeba udělat něco opatrnějšího.
Prvním krokem je projít jádro a přidat do každé struktury file_operations, která ji neměla, explicitní operaci llseek(). To je patch, který ovlivňuje 343 souborů. Tato práce byla z větší části provedena pomocí děsivého sémantického patche pro Coccinelle (je obsažen v changelogu patche), který se pokouší zjistit, jestli daný kód používá pozici v souboru nebo ne. Pokud se pozice v souboru používá, explicitní výchozí funkcí se stává default_llseek(), která implementuje staré chování; jinak se použije noop_llseek(), která uspěje, ale nic neudělá. Poté, co bylo tohle hotovo, byl Arnd schopen ověřit, že žádný z uživatelů default_llseek() (je jich 191) BKL nepotřebuje. Odstranění BKL z llseek() lze tedy dokonat.
Patch také mění to, jak se llseek() řeší ve vnitřním kódu jádra. Počínaje 2.6.37, za předpokladu, že tato práce bude začleněna (dalo by se na to vsadit), bude všechen kód, který neposkytne operaci llseek(), mít jako výchozí no_llseek(), která vrací ESPIPE. Všech kód mimo strom, který závisí na staré výchozí funkci, nebude s 2.6.37 fungovat, dokud nebude opraven.
I po celé této práci je v hlavní řadě stále ještě mnoho volání lock_kernel(). Téměř všechny z nich jsou ale ve starém obskurním kódu, který pro většinu uživatelů není relevantní. V některých případech by mohlo být možné přesunout kód, který používá BKL, do stromu staging a nakonec ho úplně odstranit, pokud nebude opraven. V ostatních případech bude snaha BKL odstranit; stále ho lze nalézt v kódu, který je občas užitečný - příkladem jsou implementace Appletalk a ncpfs. BKL také používá mnoho Video4Linux2 ovladačů; jak budou opraveny, je stále předmětem diskuzí v komunitě V4L2.
Největší překážkou pro jádro 2.6.37 bez BKL nicméně může být kód pro POSIXové zamykání. Zámky pro soubory jsou interně reprezentovány strukturou file_lock; tyto struktury jsou předávány na více míst a samozřejmě chráněny pomocí BKL. Existují patche, které tyto struktury chrání ve vnitřním kódu jádra spinlockem. Problematickým bodem je ale NFS démon lockd, který používá strukturu file_lock a tudíž BKL potřebuje; na opravě tohoto kódu prý někdo pracuje, ale žádné patche ještě zaslány nebyly. A dokud nebude konvertován lockd, zamykání souborů jako celek potřebuje BKL. A vzhledem k tomu, že jenom málokteré jádro nemá povolené zamykání souborů, zavleče to BKL do téměř všech jader.
I po opravě na tomto místě budou pravděpodobně distribuční jádra BKL potřebovat ještě o něco déle. Dokud alespoň jeden modul, který dodávají, závisí na BKL, musí být BKL k dispozici, i když většina uživatelů tento modul nepoužívá. Lidé, kteří si překládají vlastní jádra by nicméně měli být schopni přijít s konfigurací, která BKL nepotřebuje. Pokud všechno půjde dobře, bude mít 2.6.37 konfigurační volbu, která umožní překlad bez BKL. To bude velkým krokem kupředu, i když BKL bude stále existovat v mnoha dodávaných jádrech.
napsal Jake Edge, 22. září 2010
Chyba v jádře, která byla nalezena – a opravena – roku 2007, na nás znovu vystrčila hlavu. Chyba byla bohužel do jádra znovu zatažena roku 2008, čímž vznikla poměrně velká hromádka jader, která umožňují lokální eskalaci práv na systémech s x86_64. I když by bylo těžké ji vytvořit, zdá se, že by se hodilo mít nějakou sadu na testování regresí, která by v jádře detekovala takové problémy dřív, než jsou vypuštěny do světa.
Jsou zde dvě částečně související chyby, které obě poletují kolem a způsobují tak zmatek. Jedna byla původně CVE-2007-4573 a byla znovu zatažena pročišťujícím patchem v červnu 2008. Tato znovu zatažená slabina byla označena jako CVE-2010-3301 (i když v době psaní tohoto článku je tento záznam pouze rezervován). Ben Hawkes našel podobnou slabinu – která také zneužívá systémová volání z 32bitových binárek na 64bitových systémech x86 – což ho vedlo k objevení znovu zatažené CVE-2007-4573.
Práce s 32bitovými binárkami na 64bitových systémech má mnoho obtíží. Linux má sadu funkcí, které řeší rozdíly v parametrech a konvencích mezi 32bitovými a 64bitovými systémovými voláními, ale vždy bylo těžké udělat to správně. To, co vidíme nyní, jsou dva případy, kdy to nebylo uděláno korektně a kdy jsou důsledky katastrofální.
Problém z roku 2007 pocházel z toho, že se čísla systémového volání (které je indexem v tabulce systémových volání) ukládalo do 32 bitového registru %eax, zatímco pro indexování se použil 64 bitový registr %rax (jehož spodních 32 bitů obsahuje %eax.) V "normální" cestě pro systémová volání se %eax před uložením čísla systémového volání z uživatelského prostoru doplnil nulami, ale do tohoto kódu se bylo možné dostat i druhou cestou, kde se horních 32 bitů %rax nevynulovalo.
Systémové volání ptrace() má možnost vyvolat jiná systémová volání (použitím typu požadavku PTRACE_SYSCALL) a také uživateli umožňuje nastavit hodnoty registrů. Útočník mohl nastavit horních 32 bitů %rax dle libosti a zavolat systémové volání se zdánlivě platným indexem (uloženým v %eax) a tak indexovat kód někde mimo tabulku systémových volání. Když zajistil, aby se kód exploitu nalézal na daném místě, mohl útočník zajistit, aby ho jádro spustilo.
Tuto cestu pomocí ptrace() opravil Andi Kleen v září 2007 tak, že zajistil, aby se %eax a ostatní registry doplňovaly nulami. Doplňování u %eax ale odstranil pročišťovací patch Rolanda McGratha z června 2008. Když si Ben a Robert Swiecki nedávno všimli problému, nedělalo jim potíže modifikovat exploit z roku 2007 a na aktuálních jádrech získat roota.
CVE-2010-3301 bylo vyřešeno párem patchů. Roland vrátil zpátky doplnění nul k registru %eax, zatímco H. Peter Anvin upravil test platnosti čísla systémového volání tak, aby se kontroloval celý registr %rax. Každý z nich by uzavřel tuto bezpečnostní díru sám o sobě, ale Peterův patch ochrání všechny ostatní cesty ke kódu vstupu do systémového volání, takže by v budoucnosti neměly narazit na podobný problém.
Z faktu, že šlo použít starý exploit, vyplývá, že roku 2007 někdo mohl napsat test, který by detekoval opětovné zavedení tohoto problému. Sada takových testů na regrese, která by se pravidelně spouštěla oproti hlavní řadě, by byla jako cesta k omezení počtu regresí poměrně užitečná - jak pro normální chyby, tak pro bezpečnostní díry. Ne všechny chyby bude možné takovým způsobem testovat, ale pro ty, kde by to možné bylo, se to zdá jako nápad, který by bylo dobré realizovat.
Druhý problém, který Ben nalezl (CVE-2010-3081, také pouze rezervováno), spočívá v tom, že funkce compat_alloc_user_space() nekontrolovala, jestli je vracený ukazatel opravdu platným ukazatelem v uživatelském prostoru. Tato rutina se používá k alokaci nějakého místa na zásobníku pro úpravu 32 bitových dat do 64 bitového ekvivalentu před samotným systémovým voláním. Ben našel dvě místa (a věří, že jich je víc), kde lze chybějící volání access_ok() v dané cestě zneužít k tomu, aby útočník mohl zapisovat do paměti jádra.
Jedním z nich bylo ioctl() pro video4linux, ale snáze šlo zneužít místo ve volání getsockopt() pro IP multicast. To používá 32 bitový neznaménkový parametr předaný uživatelským prostorem, který lze použít ke zmatení compat_alloc_user_space() tak, aby vrátila ukazatel do jaderné paměti.
Volání compat_mc_getsockopt() s použitím tohoto ukazatele potom zapíše uživatelem dané hodnoty. To lze snadno upravit v exploit, Ben napsal:
Peter Anvin opatchoval compat_alloc_user_space(), aby vždy používala kontrolu access_ok(). To by mělo vyřešit oba problémy, které našel Ben, stejně jako další, které se tam skrývaly. Bylo zde ale mnoho jader vydaných s jednou nebo oběma těmito chybami a co se týče 32/64 bitové kompatibility, byly zde i další chyby. O této části jádra Ben říká, že je trošičku děsivá:
Možná by 32 bitová kompatibilita u jader pro x86_64 byla dobrým místem, kde začít testovat regrese. Některé podnikové distribuce nebyly CVE-2010-3301 postiženy, protože jsou založeny na prastarých jádrech (jako 2.6.18 v RHEL), ale CVE-2010-3081 bylo do RHEL 5 backportováno, což vynutilo aktualizaci tohoto jádra. Je jenom v zájmu distributorů dělat lepší – jakékoliv – testy na regrese, takže projekt tohoto typu by byl jenom vítán. Dodavatelé možná nějaké testy dělají již nyní interně, ale testování regresí by mohla hodně vytěžit z mezidistribuční spolupráce.
Stojí za to poznamenat, že v e-mailové konferenci full-disclosure se objevil příspěvek, ve kterém se tvrdí, že černé (nebo šedé) klobouky o chybě v compat_mc_getsockopt() ví již téměř dva a půl roku. Podle příspěvku si jí všimli, když byla tato slabina zavedena v dubnu 2008. Lidé, kteří sledují proud commitů, aby našli podobné chyby, tu rozhodně jsou; bylo by dobré, kdyby jádro mělo tým bílých klobouků, kteří budou dělat totéž.
napsal Jonathan Corbet, 22. září 2010
Nedávno vydané open source ovladače pro bezdrátová síťová zařízení od Broadcomu jsou významným krokem pro firmu, která až doteď nebyla příliš vstřícná, když došlo na svobodnou podporu jejich zařízení. Ovladač zahrnuje nutný blob s firmwarem, jehož licence umožňuje volné šíření; nyní je k nalezení v archivu firmwaru v jádře. Broadcom nicméně neuvolnil firmware pro starší ovladače, což vede k diskuzi o průniku mezi vývojem jádra a dodržováním předpisů.
Chybějící volně distribuovatelný firmware pro starší produkty od Broadcomu trochu ztěžuje život uživatelům, kteří si firmware musí sehnat sami. Když byl uvolněn nový firmware, David Woodhouse se zeptal firmy, jestli bude uvolněn i starší firmware, ale bylo mu řečeno, že ne. V jeho podání se Broadcom obává, že uvolnění firmwaru k distribuci by vedlo k potížím:
Důvod, proč se starý firmware liší, je jednoduchý: novější firmware, který může běžet jenom na novějším hardware, má dodržování předpisů zabudované. Starší firmware naopak závisí na ovladači v jádře, který má zajistit, aby zařízení nebylo nakonfigurováno způsobem, který by dovolil porušit předpisy.
David není znám tím, že by jenom tiše trpěl, když narazí na (lidi, které považuje za) hlupáky. Jeho reakcí byl patch, který "děkuje" Broadcomu za to, že umožnil vývoj ovladače b43 pomocí reverzního inženýrství; toto "umožnění" vzniklo díky tomu, že poskytli binární ovladače, které reverzní inženýrství umožnily. Cílem tohoto patche je:
Také vyjádřil přání, aby vývojáři b43 uvolnili více informací – získaných z binárních ovladačů – o tom, jak tyto binární ovladače opatchovat, aby se obešla různá omezení kvůli předpisům. I zde má pocit, že tato informace by pomohla v tom, aby bylo jasné, že svobodné ovladače nijak nezjednodušují provoz hardwaru proti předpisům.
Davidova pozice vyhovuje vývojářům, kteří nemají žádné pochopení pro překážky, které jim do cesty hází právníci. Také je zde hlasitá skupina, která tvrdí, že Linux nemá uživatelům co kecat do toho, jak mají používat svůj hardware; jestliže uživatel chce nakonfigurovat hardware tak, že nebude splňovat předpisy, je to problém toho uživatele. V některých případech může uživatel mít licenci, díky které je zcela v pořádku, když hardware poběží mimo parametry, které se normálně vztahují na vybavení koupené v obchodě. Dodržování předpisů tedy přirozeně štve vývojáře, kteří si myslí, že jádro nemá v popisu práce plést se komukoliv v tomto ohledu do cesty.
Luis Rodriguez je na druhou stranu silným zastáncem dodržování předpisů v linuxovém jádře; vstoupil do diskuze, připomněl lidem vyjádření o dodržování předpisů v jádře a řekl, že ve skutečnosti není žádný zájem v tom podporovat porušení předpisů o využívání spektra v žádném ovladači. Dodal:
Pointou je, že jaderné „“technické řešení“ problému regulací umožnilo dodavatelům bezdrátových zařízení smočit prsty v open-source vodách. To následně vedlo k tomu, že se Linux od mizerné podpory bezdrátových zařízení během několika let posunul k možná nejlepší podpoře. Jen těžko lze popřít úspěchy, které měli vývojáři ovladačů pro tato zařízení v nedávné době; jakékoliv kroky, které by tento úspěch mohly ohrozit, by měly být přinejmenším pečlivě zváženy.
Samozřejmě by bylo hezčí úplně se obejít bez proprietárních blobů. Začátkem roku 2009 projekt openfwwf oznámil dostupnost open source implementace firmwaru pro karty od Broadcomu. Od té doby byly novinky z tohoto projektu relativně vzácné; 21. září nicméně Michael Büsch oznámil, že je k dispozici sada nástrojů pro práci s firmwarem b43. S pomocí disassembleru a assembleru je možné dekódovat firmware zařízení, provést změny a pak vytvořit nový firmware. Přirozeně je samozřejmě možné vytvořit novou implementaci firmwaru od začátku. S těmito nástroji bychom se mohli dostat do bodu, kdy budeme mít firmware bez omezení distribuce a kdy bude možné rozšířit vlastnosti i flexibilitu zařízení.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
12.10.2010 16:11
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
12.10.2010 15:04
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Doufejme, David Woodhouse bude jen tise trpet, az nejaky vycurany pravnik opravdu zazaluje Broadcom a, svete div se, vyhraje.Až se tohle stane, tak to nebude prohra (jen) Davida Woodhouse či Broadcomu, ale především demokratické justice.
13.10.2010 17:10
Jardík | skóre: 40
| blog: jarda_bloguje
Ale jinak souhlasim s tim, ze menit mrtve odkazy za odkazy na web.archive.org je blbost. Mozna za ne pridat " (web.archive.org)" aby se pri pristi aktualizaci dokumentace nezkousely znova.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz