Ondřej Filip publikoval reportáž z ceremonie podpisu kořenové zóny DNS. Zhlédnout lze také jeho nedávnou přednášku Jak se podepisuje kořenová zóna Internetu v rámci cyklu Fyzikální čtvrtky FEL ČVUT.
Společnost BenQ uvádí na trh novou řadu monitorů RD určenou pro programátory. První z nich je RD240Q.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem nadále zůstává Frontier od HPE (Cray) s výkonem 1,206 exaFLOPS. Druhá Aurora má oproti loňsku přibližně dvojnásobný počet jader a dvojnásobný výkon: 1,012 exaFLOPS. Novým počítačem v první desítce je na 6. místě Alps. Novým českým počítačem v TOP500 je na 112. místě C24 ve Škoda Auto v Mladé Boleslavi. Ostravská Karolina, GPU
… více »GHC (Glasgow Haskell Compiler, Wikipedie), tj. překladač funkcionálního programovacího jazyka Haskell (Wikipedie), byl vydán ve verzi 9.10.1. Přehled novinek v poznámkách k vydání.
Po 9 týdnech vývoje od vydání Linuxu 6.8 oznámil Linus Torvalds vydání Linuxu 6.9. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna. Později také na Linux Kernel Newbies.
Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
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