Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Současný vývojový kernel je 4.8-rc6, vydaný 11. září. „Stále jsem se ještě nerozhodl, zda uděláme rc8, ale myslím, že zatím nemusím spěchat. Nic nevypadá úplně zle a bude záležet na tom, jak dopadne rc7.“
Seznam známých regresí v řadě 4.8 měl k 11. září 10 položek.
Stabilní aktualizace: 3.14.79, poslední z řady 3.14.x, byla vydána 11. září.
Stabilní aktualizace 4.7.4 (oznámení chybí) a 4.4.21 byly v době vydání tohoto článku v procesu revidování, nyní by již měly být dostupné.
Jenže se ukázalo, že příslušnou řadu jádra používali pouze po nějakou dobu během vývoje, načež s tím přestali, jakmile se zařízení dostalo na trh. Podívejte se na všechny ty telefony s Androidem, které využívají zastaralé verze stabilních jader 3.4 a 3.10. Už je ani neaktualizují na novější, a tak to vlastně skoro nijak nepomohlo. Přestože v těchto jádrech pořád opravuji bezpečnostní chyby, nikdo to neposílá dál uživatelům. Mám příklad bezpečnostní chyby, kterou jeden vývojář z Google našel v jádře 3.10 (ale ne v upstreamu). Opravil jsem ji a vydal aktualizaci, tu ale nikdo celých šest měsíců nedostal do telefonů Nexus – až jsem po těch šesti měsících našel toho správného člověka/skupinu, kterou bylo třeba v Google postrčit.
Takže kdokoli měl k dispozici šestiměsíční okno, během kterého mohl snadno získat roota na vašem telefonu.
Lidé říkají: „Podívejte, ve svém produktu používáme LTS jádro, takže všechno musí být v pořádku!“ Ale pokud jej neaktualizují, je rozbité a nezabezpečené a vůbec o nic lepší, než kdyby rovnou použili 3.10.0.
Nezbývá mi než dodat:
yell_WTF(nr_wtf_moments);
Hodnotu argumentu funkce ponechám na vaší představivosti.
Leif Lindholm začal pracovat na seriálu o psaní ovladačů UEFI. „Vzhledem k tomu, že jsem vlastně nikdy ovladač UEFI nenapsal na zelené louce a většina ovladačů, se kterými jsem se dostal do styku, byly hlavně ovladače platformy, řekl jsem si, že by nebylo špatné napsat samostatný ovladač celý od počátku. Výsledkem je tento lehce praktický seriál.“
Cílem většiny útoků na jádro je spustit kód dle útočníkova výběru, s právy jádra. Není tedy překvapením, že existuje mnoho technik tvrzení, které jsou zaměřeny na prevenci vložení libovolného kódu do míst, kde by napadené jádro mohlo být přesvědčeno k jeho spuštění. Bohužel návrh jaderného subsystému správy paměti je takový, že řadu technik bránících v přístupu lze obejít. Aktuálně koluje sada patchů, jež má za cíl tuto „díru“ zavřít, přináší však s sebou také zajímavou otázku: je jaderná komunita ochotna obětovat výkon, aby se dosáhlo lepšího zabezpečení?
Útočník, který chce, aby jádro spustilo libovolný kód, čelí problému: kam takový kód vložit, aby ho jádro mohlo spustit? V případě, že je možné jádro přesvědčit, aby spustilo kód, který se nachází v uživatelském prostoru, je mnohem jednodušší tento problém vyřešit, protože vložit kód do paměti uživatelského prostoru zvládne každý. Vzhledem k tomu, že paměť uživatelského prostoru zůstává namapovaná, i když procesor běží v jaderném režimu, vše co je třeba udělat, je přesvědčit jádro, aby skočilo na adresu v uživatelském prostoru. Před lety bylo možné jednoduše namapovat stránku na adrese 0 a najít chybu, která by způsobila, že jádro přeskočí na ukazatel na null. Takové jednoduché útoky se podařilo eliminovat, ale složitější exploity jsou stále běžné.
Je jasné, že nejlepším řeším je ujistit se, že se jádro nikdy nepokusí skočit na adresu v uživatelském prostoru. Pokud se však smíříme s tím, že chyby budou vždycky existovat, má smysl přidat další ochranu, a sice jednoduše zabránit jádru ve vykonávání kódu z paměti uživatelského prostoru. Mechanismy PaX KERNEXEC a UDEREF jsou navrženy tak, aby těmto typům přístupu do uživatelského prostoru zabránily. Nedávno se do hry přidali také výrobci procesorů: Intel nyní má SMAP (Supervisor Mode Access Prevention) a SMEP (Supervisor Mode Execute Protection), zatímco ARM přidal PXN (Privileged Execute-Never). Na systémech, kde jsou tyto mechanismy plně implementovány, by už mělo být pro jádro nemožné spustit kód, který se nachází v paměti uživatelského prostoru.
Až na to, jak stojí v příspěvku Vasileiose P. Kermelise a kol. (PDF), že existuje skulina. Paměť uživatelského prostoru je dostupná skrze stránkovací tabulky procesu a různé mechanismy prevence přístupu pracují tak, že blokují přístup do jádra právě skrze tyto tabulky. Ale jádro zároveň udržuje lineární mapování celého rozsahu fyzické paměti (na 64bitových systémech, u 32bitových systémů je to složitější). Toto mapování má v jádře četná využití, na předních místech seznamu bychom pak našli správu paměti na úrovni stránek. Každé fyzické stránce v systému poskytuje samostatnou adresu. Co je zásadní, jedná se o adresu v jaderném prostoru a na některých systémech (x86 před verzí 3.9, ARM všeobecně) je obsah paměti v tomto rozsahu vykonatelný jádrem.
Jestliže útočník přinutí jádro skočit na přímo mapovanou adresu, nedostane se žádný z mechanismů zabraňujících přístupu k uživatelskému prostoru do hry, a to ani v případě, že cílová adresa odpovídá stránce v uživatelském prostoru. Přímé mapování tedy nabízí pohodlný způsob, jak tyto ochrany obejít. Má to jen jeden háček: útočník musí být schopen určit fyzické stránky obsahující škodlivý kód. Jak vyplývá z příspěvku, soubory pagemap v /proc tyto informace poskytnou – přestože je možné tyto soubory zakázat, distribuce to obvykle nedělají. Takže na většině systémů je všechno připraveno k tomu, aby útočník mohl zneužít chybu, která by způsobila skok na libovolnou adresu, zatímco existující ochranné mechanismy by byly naprosto bezmocné.
(Trošku složitější je to na současných jádrech pro x86, kde již není možné přímo spouštět kód skrze přímé mapování. V takovém případě se útočník musí uchýlit k programování zaměřenému na návratové hodnoty (return-oriented programming) – což pro spoustu útočníků nepředstavuje velkou překážku.)
Řešením, jak bylo popsání v příspěvku a implementováno v sadě patchů exkluzivního vlastnictví stránek (XPFO), kterou zaslal Jürg Haefliger, je odebrat přístup zadními vrátky ke stránkám uživatelského prostoru skrze přímé mapování. Mechanismus je to v principu velmi jednoduchý. Kdykoli dojde k alokaci stránky pro použití v uživatelském prostoru (což jádro už teď označuje pomocí příznaků GFP v požadavku na alokaci), dojde k odstranění přímého mapování této stránky. Takže i když by se útočníkovi podařilo získat přímo mapovanou adresu stránky a přinutit jádro, aby tam skočilo, to vzhledem k nedostatku přístupových oprávnění selže. Když uživatelský prostor stránku uvolní, bude vynulována (aby se zabránilo útokům pomocí nebezpečného kódu, který ve stránce zůstal) a navrácena k přímému mapování.
Jsou samozřejmě situace, kdy jádro musí mít k paměti uživatelského prostoru přístup: funkce copy_to_user() a copy_from_user() jsou jasné příklady. V těchto případech je po dobu průběhu operace přímé mapování obnoveno.
Cenou je přirozeně výkon. Mapování a odmapování stránek v adresním prostoru jádra bude trochu zpomalovat, stejně tak nulování stránek vrácených z uživatelského prostoru. Možná, že ještě důležitější je změna implementace přímého mapování. Obyčejně jádro vytvoří takové mapování s velkými stránkami, což mj. výrazně snižuje tlak na TLB (translation lookaside buffer) procesoru při přístupu k přímému mapování. Ovšem velké stránky nejsou kompatibilní s přidáváním a odstraňováním mapování pro jednotlivé (malé) stránky v daném rozsahu, takže s přechodem na XPFO, musí jít mapování velkých stránek pryč. Dojde také ke zvýšení režie paměti vyplývající z potřeby ukládat více informací na stránce. Jinak řečeno, nastavením XPFO dojde v nejhorších případech ke snížení výkonu až o 3 %, ačkoli většina výsledků benchmarků v příspěvku výše jmenovaných autorů byla mnohem nižší.
Sada patchů vyžaduje nějaké dokončovací práce, než bude možné vážně uvažovat o jejím začlenění do upstreamu. Dá se předpokládat, že až na to dojde, stočí se konverzace k tomu, jak je sada patchů vlastně efektivní při předcházení útokům a zda za snížení výkonu opravdu stojí. Skutečnost, že zpomalení pro sestavená jádra je asi 2,5 %, by mohla představovat překážku v této diskuzi. S tak velkým úbytkem výkonu je těžké se smířit, ale totéž platí i o úspěšných útocích. Která pilulka se ukáže jako jako ta nejhořčejší, se asi ukáže, až práce na sadě patchů postoupí.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Kernel driver API tam samozrejme je, jenom je interni a meni se, coz je OK pokud je driver v mainline.
Pevné ABI není zajímavé pro vývojáře, ale spíš pro uživatele. Vývojářům out of tree driverů komplikují život změny API, kvůli kterým je musejí zaplevelit hromadami ifdefů, nejčastěji podle verzí (což je zase problém u distribučních jader). Vývojáře netrápí změny ABI, to jen znamená, že je potřeba modul přeložit proti danému jádru.
Koho zajímá ABI, to jsou uživatelé third party driverů, a to zejména těch closed source. Proto se snaží při běžných updatech zachovávat kABI enterprise distribuce. Ale taky to není žádný med, někdy se kvůli tomu musejí vymýšlet hodně divoké obezličky a občas to nejde vůbec.
naivní kódVím, že to bude nativní kód, ale překlep pobavil
.
Jinak dost nebezpečný teda, nepředpokládám, že ke všemu budou zdrojáky :-/.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz