OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Aktuální vývojová verze jádra je 3.6-rc7 vydaná 23. září. Tato verze zahrnuje změnu kódového názvu na „Vyděšený čipmank“. Linus k tomu řekl: Takže jestli všecho dobře dopadne a blížící se týden bude ve znamení klidu, tak se snad vyhnu dalšímu -rc. Držím tomu palce.
Stabílní aktualizace: verze 3.2.20 vyšla 20. září.
Přijali jsme skutečnost, že memcg stojí za houby. Ale nemohlo by se to místo stání pohybovat rychleji?
K tomuto mě přivedlo hlášení chyby z loňského února, kde si autor stěžuje na 200mikrosekundové nárazové latence pocházející z ochranné lhůty v RCU. Na systémech s 4096 procesory.
Odezva v reálném čase. Větší hukot, než jsem si myslel.
Zmínil jsem to jen proto, abych viděl, zda tvůj detektor virtuálních blbin stále funguje. Vypadá to, že je nadále v nejlepší kondici, má nízkou odezvu a 100% úspěšnost.
-- Avi Kivity
Funkce transparentních velkých stránek umožňuje aplikacím využívat podpory větších velikostí stránek ve většině současných procesorů bez potřeby explicitní konfigurace ze strany administrátorů, vývojářů nebo uživatelů. Jde především o funkci zvyšující výkon: velké stránky snižují tlak na TLB, čímž zrychlují přístupy k paměti. Může dojít i k úspoře trochy paměti následkem odstranění vrstvy tabulek stránek. Jenže se nakonec ukázalo, že transparentní velké stránky mohou využití paměti aplikacemi zvyšovat v závislosti na okolnostech. Dobrou zprávou je to, že řešení je nasnadě.
Transparentní velké stránky se používají hlavně pro anonymní stránky – stránky, které nejsou „kryté“ souborem na disku. Tyto stránky formují datové oblasti procesů. Jakmile je oblast anonymní paměti vytvořena nebo rozšířena, nejsou ve skutečnosti žádné stránky alokovány (ať už jsou transparentní velké stránky povoleny, nebo ne). To je kvůli tomu, že typický program nakonec nikdy neupraví celou řadu stránek, které ve svém paměťovém prostoru má; alokace stránek před prokázáním jejich potřeby by bylo mrháním znatelného množství času a paměti. Proto jádro čeká, než se proces pokusí přistoupit ke konkrétní stránce, dojde tím k výpadu stránky (page fault) a dodatečnému namapování.
I tak je ale možné udělat optimalizace. Nové anonymní stránky musejí být naplněny nulami; cokoliv jiného by bylo bezpečnostím rizikem, kdy může dojít k předání dat, které tam dříve umístil jiný uživatel. Programy dále často na inicializaci paměti závisí; samy si paměť neinicializují, když ví, že to není potřeba. Jak se také ukázalo, do spousty těchto stránek není nikdy nic zapsáno; zůstávají naplněny nulami po celou dobu své existence. Jakmile se na tuto skutečnosti přišlo, rychle byl na světě další nápad na optimalizaci v podobě sdílení těchto stránek plných nul. Jedna nulová stránka vypadá stejně jako jakákoliv jiná, takže nemá význam jich dělat spousty.
Proto, kdykoliv proces vytvoří novou (nikoliv velkou) stránku tím, že se z ní pokusí číst, jádro přesto nealokuje novou stránku. Namísto toho namapuje do paměťového prostoru procesu speciální stránku, které se jednoduše říká „nulová stránka“. Tato stránka je logicky vždy mapována jen ke čtení; aby jeden proces nemohl měnit obsah druhému. Kdykoliv se proces pokusí do této stránky zapisovat, dojde k chybě na základě ochrany proti zápisu; jádro pak (konečně) alokuje skutečnou stránku a tu umístí do prostoru procesu na to správné místo.
Toto chování je jednoduché vypozorovat. Jak to Kirill Shutemov popsal, proces. který spustí následující:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
posix_memalign((void **)&p, 2 * MB, 200 * MB);
for (i = 0; i < 200 * MB; i+= 4096)
assert(p[i] == 0);
pause();
bude mít překvapivě málo využité paměti RAM v době volání pause(). V ten moment to prošlo 200 megabajty paměti, ale všechna tato paměť je vyjádřena jedinou nulovou stránkou. Systém funguje tak, jak bylo zamýšleno.
Nebo spíš jen do doby, než povolíte funkci transparentních velkých stránek; pak bude proces vykazovat 200 MB alokované paměti. Nárůst paměti o dva řády není zrovna ten typ výsledků, jaký uživatelé očekávají při povolení funkce, která má zvyšovat výkon. Proto Kirill říká, že toto přihání některé lidi k vypnutí této funkce v sebeobraně.
Problém je jednoduchý: žádná velká nulová stránka neexistuje. Funkce transparentních velkých stránek se snaží tyto stránky používat, kdykoliv je to možné; když proces způsobí výpadek v nové stránce, jádro se tam pokusí umístit velkou stránku. Protože žádná velká nulová stránka neexistuje, tak místo toho prostě alokuje skutečnou nulovou stránku. Toto chování vede ke korektnímu vykonání programu, ale způsobuje také alokaci spousty paměti, která by jinak nebyla nutná. Tato funkčnost tedy ve zkratce vypíná důležitou optimalizaci, která byla součástí jaderné správy paměti po mnoho let.
Jakmile byla pochopena příčina problému, nalezení řešení nebylo obtížné. Kirillův patch přidává speciální velkou stránku plnou nul, která zaujímá místo nulové velké stránky. Při používání této stránky při výpadcích při čtení spotřeba paměti zmizí.
Jak tomu tak bývá, má to i své zapeklitosti: stránka je natolik velká, že se hodí, aby nebyla alokována, když se transparentní velké stránky nepoužívají. Proto se používá schéma opožděné (lazy) alokace; Kirill také přidal čítač referencí, aby bylo možné nulovou velkou stránku uvolnit, jakmile není dále potřeba. Počítání referencí zpomaluje benchmark sledující výpadky při čtení o jedno procento, takže není jasné, jestli to za to stojí; vývojáři mohou nakonec dospět k názoru, že bude lepší stránku po první alokaci zanechat a vyhnout se tak náročnosti počítání referencí. To je konec konců to, k čemu se dospělo s (malými) nulovými stránkami.
Tomuto patchi se zatím nedostalo přílišného počtu komentářů; implementace je relativně přímočará a snad ani nevyžaduje tolik změn. Vzhledem ke zjevné přínosnosti patche se dá očekávat zařazení v brzké době; vývojový cyklus verze 3.8 by asi byl rozumným cílem.
Návrháři operačních systémů a hardwaru obvykle věnují hodně času úvahám, jak je možné chránit jádro od přístupu ze strany procesů v uživatelském prostoru. Bezpečnost systému jako celku na této ochraně závisí. Smysl ale může mít i ochrana uživatelského prostoru proti jádru. Linuxové jádro bude brzy mít podporu pro novou funkci procesorů od Intelu, která má právě toto umožnit.
Ve všech situacích, snad kromě zvláštních úprav mimo hlavní strom jádra, je paměť jádra vždy mapována, takže kód v uživatelském prostoru by teoreticky mohl tuto paměť číst a upravovat. Ochrana stránek je ale nastavena tak, aby takový přístup nebyl možný; jakýkoliv pokus zkoumat nebo měnit části paměti náležící jádru vede k signálu SIGSEGV. Přístup druhým směrem už není takto chráněn: když je procesor v režimu jádra, tak má plný přístup k libovolné adrese v tabulce stránek. Respektive téměř plný; procesor nadále obvykle neumožní zápis do stránky, která je jen ke čtení, ale tuto ochranu je podle potřeby možné vypnout.
Nová funkce „Supervisor Mode Access Prevention“ (SMAP; Ochrana proti přístupu supervizora) od Intelu tuto situaci mění; koho zajímají podrobnosti, ten je může najít od strany 408 dále v tomto referenčním manuálu (PDF). Rozšíření definuje nový bit SMAP v řídícím registru CR4; když je tento bit nastaven, jakýkoliv přístup k paměti uživatelského prostoru při běhu v privilegovaném režimu způsobí výpadek stránky. Podporu pro tuto funkci v Linuxu zaslal H. Peter Anvin a dostalo se jí obecně pozitivních reakcí; mohlo by se to dostat do hlavní řady už ve verzi 3.7.
Někdy se samozřejmě objevují situace, kdy jádro potřebuje pracovat s pamětí uživatelského prostoru. Proto Intel definoval další příznak „AC“, který funkci SMAP řídí. Pokud je příznak AC nastaven, pak je ochrana SMAP aktivní; jinak je přístup do paměti v uživatelském prostoru povolen. Přibyly dvě nové instrukce (STAC a CLAC) umožňující relativně rychlé změny tohoto příznaku. Nepřekvapí, že většina Peterova patche se zabývá právě umístěním instrukcí STAC a CLAC na správná místa. Funkce pro přístup k uživatelskému prostoru (například get_user() nebo copy_to_user()) jednoznačně potřebují mít přístup povolen. Mezi další taková místa patří přechody mezi uživatelským režimem a jádrem, operace futexů, ukládání stavu čísel s plovoucí desetinnou čárkou a tak dále. Ošetřování signálů má jako obvykle speciální potřeby; Peter musel udělat jisté významné změny, aby umožnil doručování signálů bez nadbytečné režie.
Když už se bavíme o režii, tak i podpora pro tuto funkci nebude úplně zadarmo. Funkce pro přístup k uživatelskému prostoru bývají expandovány jako inline, takže bude v jádře plno instrukcí STAC a CLAC. Mechanismus „alternativ“ je používán k tomu, aby byly za běhu odstraněny, když se funkce SMAP nepoužívá (ať už funkce není podporována jádrem nebo je vypnutá parametrem nosmap), jádro se ale trochu zvětší tak či tak. Instrukce STAC a CLAC navíc potřebují trochu času, než se vykonají. Zatím ještě nebyly zaslány žádné benchmarky, aby bylo zhodnoceno, jak vysoká daň se na tuto funkci váže; dá se předpokládat, že bude sice malá, ale bude.
Jádro bude přistupovat k porušením SMAP jako ke každému jinému přístupu k nesprávnému ukazateli: výsledkem bude oops.
Člověk by se mohl ptát, jaký smysl ochrana má, když si ji jádro může vypínat podle potřeby. Odpovědí je to, že je tak možné zamezit celé skupině exploitů, kdy je jádro navedeno k tomu, aby četlo (nebo zapisovalo) do paměti procesu „omylem“. Sada zranitelností s nulovým ukazatelem je dobrou ukázkou. Vyskytla se celá spousta situací, kdy se útočníkovi podařilo najít způsob, jak dohnat jádro k používání špatného ukazatele, zatímco případů, kdy se útočníkovi povedlo spustit libovolný kód jádře (před zneužitím špatného ukazatele), je podstatně méně. SMAP by mělo umožnit elegantní blokování běžnějších útoků.
Jinou předností je pak pochopitelně nalezení chyb v jádře. Autoři ovladačů by měli vědět, že nemohou v jádře přímo dereferencovat ukazatel z uživatelského prostoru, ale některý kód to tak na jistých architekturách dělá tak jako tak. Se zapnutým SMAP bude tento typ chyb odhalen a opraven dříve, než se dostane do hlavní řady jádra. Jak tomu tak mnohdy bývá, tak skutečně má význam, aby systém vynucoval pravidla, která mají vývojáři dodržovat.
Linusovi se sada patchů líbila a nikdo si nestěžoval, takže si změny našly svou cestu do stromu „tip“. To znamená, že je pravděpodobné, že je brzy znovu uvidíme, pravděpodobně po otevření začleňovacího okna verze 3.7. Chvíli ale potrvá, než se dostaneme k procesorům s touto funkcí; SMAP by se mělo prvně objevit v řadě Haswell, která by se měla dostat na trh v roce 2013; Jakmile ale bude hardware dostupný, Linux už bude schopen této nové funkce využít.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Autoři ovladačů by měli vědět, že nemohou v jádře přímo dereferencovat ukazatel z uživatelského prostoru.Nejsem sice kernel ani driver vývojář a o Linuxu toho moc nevím, ale jak se má tedy jádro nebo driver chovat když mu uživatel řekne "hele tady je pointer na ta data co jsme si domluvili v dokumentaci, tak je zpracuj, ale možná jsem ti kecal"? Teda kromě očividného přístupu: všechna data pečlivě zkontrolovat. Nojo ale to se děje až po dereferencování toho ukazatele.
(ale dík za upozornění).
Každopádně v copy_to_.. funkcích ten přístup povolenej bude, takže je stačí ukecat, aby zapsaly kam nemají. Jinak ale ukecání jádra, aby zapsalo na špatný pointer je imho chyba ochrany jádra od přístupu ze strany userlandu. To bylo zřejmě příčinou nedorozumění, protože když už jsem jednou v kernelu jako kód, tak už userland ten SMAP neochrání.
uzavřené moduly třetích stran, které nemají Linuxoví hackeři pod kontrolou (VMware, nVidia)
Ten VMware bych zrovna jako příklad nejmenoval. Jejich moduly jsou open source a přinejmenším podstatnou část z nich se VMware opakovaně snaží dostat do upstreamu (naposledy předevčírem submitnuli vmci a vsock), přičemž důvodem, proč to bylo dosud odmítáno, nebyla kvalita kódu.
) jádro, je to hodně účinné