D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
CreepyLink.com je nový zkracovač URL adres, 'díky kterému budou vaše odkazy vypadat tak podezřele, jak je to jen možné'. Například odkaz na abclinuxu.cz tento zkracovač převádí do podoby 'https://netflix.web-safe.link/logger_8oIlgs_free_money.php'. Dle prohlášení autora je CreepyLink alternativou ke zkracovači ShadyURL (repozitář na githubu), který dnes již bohužel není v provozu.
Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.
Wikipedie slaví 25. výročí svého založení. Vznikla 15. ledna 2001 jako doplňkový projekt k dnes již neexistující encyklopedii Nupedia. Doména wikipedia.org byla zaregistrována 12. ledna 2001. Zítra proběhne v Praze Večer svobodné kultury, který pořádá spolek Wikimedia ČR.
Po více než dvou letech od vydání předchozí verze 2.12 byla vydána nová stabilní verze 2.14 systémového zavaděče GNU GRUB (GRand Unified Bootloader, Wikipedie). Přehled novinek v souboru NEWS a v aktualizované dokumentaci.
Google Chrome 144 byl prohlášen za stabilní. Nejnovější stabilní verze 144.0.7559.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 10 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
Microsoft zveřejnil zdrojový kód XAML Studia a uvolnil ho pod MIT licencí. XAML Studio je nástroj ze světa Windows, určený pro tvorbu uživatelského rozhraní aplikací pomocí XAML (Extensible Application Markup Language). Stalo se tak zhruba po osmi letech od prvního prohlášení Microsoftu, že se tento kód chystá zveřejnit.
TimeCapsule, 'časová kapsle', je jazykový model trénovaný výhradně na datech z určitých míst a časových období, aby se tak napodobila autentická slovní zásoba, způsob vyjadřování a názory dané doby. Na Hugging face jsou k dispozici modely natrénované na historických textech dostupných v oblasti Londýna mezi lety 1800 až 1875.
Radicle byl vydán ve verzi 1.6.0 s kódovým jménem Amaryllis. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
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