Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.
VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.
V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Aktuální vývojová verze jádra je 3.13-rc2 vydaná 29. listopadu. Linus k ní řekl: Vracíme se k obvyklému týdennímu cyklu, i když mám v plánu se nakonec vrátit k vydávání v neděli. Do té doby bude každý pátek jako Vánoce! I když by se vzhledem k datu hodilo říct spíš chanuka.
Stabilní aktualizace: verze 3.12.2, 3.11.10, 3.10.21 a 3.4.71 vyšly 29. listopadu; byly následovány (velkými) vydáními 3.12.3, 3.10.22 a 3.4.72 4. prosince. Ačkoliv podpora řady 3.11.x skončila vydáním 3.11.10, Canonical bude udržovat svou verzi 3.11 až do srpna 2014.
Přístup „Cokoliv, co nepadá, je v pořádku“ tady nefunguje, jelikož nemůžeme měnit chování, na kterém závisí uživatelský prostor. Pokud nebude aktivně řízeno to, co vystavujeme z jádra, tak se pak budeme muset držet nezamýšlených vlastností současné implementace. To škodí jádru i uživatelskému prostoru. Nakonec bychom v budoucnu museli obcházet hloupá omezení a uživatelský prostor by se pak divil, kdyby v krajních případech takové hacky nevyhnutelně přestaly fungovat.
-- Tejun Heo
V jádře máme různé druhy velmi komplexního kódu a zvládáme to. Zahodit užitečné nápady jen kvůli tomu, že vypadají na první pohled příliš složitě, je téměř vždy špatně.
-- Ingo Molnar
Blogový zápisek od Citus Data popisuje problémy, které se objeví, jakmile pracovní sada [working set] databáze překročí maximální velikost aktivního seznamu jádra. Ukazuje se, že LRU má dva nedostatky při používání jako algoritmus pro nahrazování stránek. Zaprvé je přesná implementace LRU v tomto kontextu příliš náročná. Zadruhé musí správce paměti zohledňovat i frekvenci, aby čtení velkého souboru nevyprázdnilo celou cache. Proto Linux používá sofistikovanější algoritmus než LRU; a tento algoritmus nefunguje dobře při zátěži, co jsme zrovna popsali.
Na opravě tohoto problému se pracuje od roku 2012; práce na ní se před časem oživila a v brzké budoucnosti může být začleněna. Mezitím tento problém vyvolal na mailing listu PostgreSQL debatu o tom, jestli je linuxové jádro spolehlivou platformou pro databázové aplikace.
Pád jádra nahlášený poprvé v červenci ve verzi 3.10 se konečně podařilo diagnostikovat. Současně s tím bylo opraveno nějaké to pochybné zamykání v kódu pro roury, ale má to ještě i zajímavější výsledek: vypadá to, že „zjevně správný“ kód čítače referencí není nakonec tak správně. Pro pochopení důvodů je nutné se podívat na podrobnosti toho, jak jsou mutexy v linuxovém jádře implementovány.
Z návrhového hlediska je jaderný mutex jednoduchým zámkem pro spaní. Jakmile je zámek převzat pomocí mutex_lock(), pak má jeho držitel výhradní přístup ke chráněným prostředkům. Jakékoliv jiné vlákno při snaze získat ten samý zámek bude blokováno, dokud nebude zámek uvolněn. V praxi je implementace o něco složitější. Jak bylo poprvé předvedeno v kódu Btrfs, výkon je možné zlepšit, pokud vlákno, které narazilo na uzamčený zámek, bude krátce aktivně čekat (a doufat, že zámek bude brzy uvolněn), než přejde do spánku. Běžící vlákno, které může takto rychle získat zámek, bude ještě v cache, takže tento typ optimistického čekání má tendenci zlepšovat celkovou propustnost systému. Není ani třeba dodávat, že doba aktivního čekání by měla být relativně krátká; navíc k němu nedojde, pokud už nějaké jiné vlákno aktivně čeká nebo pokud vlastník mutexu neběží.
Teď, když jsme si vysvětlili teorii, se podívejme na kus kódu, který pracuje se strukturou nazvanou "s"; tato struktura je chráněna mutexem, který je v ní obsažen:
int free = 0; mutex_lock(&s->lock); if (--s->refcount == 0) free = 1; mutex_unlock(&s->lock); if (free) kfree(s);
Tento kód vypadá, že by měl fungovat dobře; struktura je uvolněna pouze tehdy, když už na ní nejsou žádné reference. Linus ale přišel na to, že tento kód není při současné implementaci mutexů vůbec správně.
Hlavní součástí struktury mutexu je atomický čítač (count) a spinlock (wait_lock). Když je zámek odemčený, pak má count hodnotu jedna. Zavolání mutex_lock() na odemčeném zámku jednoduše dekrementuje count na nulu a bude pokračovat; toto je nejrychlejší cesta, která při troše štěstí bude spouštěna nejčastěji. Pokud je ale zámek zabraný, pak bude count nastaven na záporné číslo (což značí, že zámek chce někdo jiný) a frustrovaný volající bude možná aktivně čekat a doufat, že count bude opět nastaveno na jedničku.
Jakmile dojde na volání mutex_unlock(), rychlá cesta (spuštěná, pokud je count nula) je opět jednoduchá: count je inkrementován zpátky na jedničku. Pokud ale count bylo záporné, pak se musí spustit pomalá cesta, aby čekající vlákna věděla, že zámek už je dostupný. Ve zjednodušené podobě dělá tento kód následující:
spin_lock(&lock->wait_lock); atomic_set(&lock->count, 1); wake_up_process(/* první čekající vlákno */); spin_unlock(&lock->wait_lock);
Problém je teď vidět: vlákno, které aktivně čeká na odemčení zámku, se ze své smyčky dostane, jakmile uvidí výsledek volání atomic_set(). Takže zatímco původní držitel zámku volá wake_up_process(), aby probudil někoho, kdo čeká na zámek, vlákno na jiném CPU už pracuje s předpokladem, že ten samý zámek drží. Pokud toto vlákno rychle uvolní datovou strukturu se zámkem, pak konečné volání spin_unlock() bude měnit paměť, která už byla uvolněna a možná zase přidělena někomu jinému. Je to dosti nepravděpodobná situace, ale původní hlášení chyby ukazuje, že se to někdy může stát.
Toto vedlo Linuse k závěru:
Jinými slovy, není bezpečné chránit čítače referencí uvnitř objektů čímkoliv jiným než spinlocky nebo atomickými čitači referencí. Nebo musíte mít zámek *mimo* objekt, který chráníte (což je často to, co z jiných důvodů tak či tak potřebujete, hlavně při vyhledávání).
Tento závěr hned vede k jiné otázce: kolik dalších míst v jádře může být postiženo takovouto chybou? Mutexy a čítače referencí se v jádře používají velmi aktivně; jistě se najdou i další místa, která je kombinují nebezpečným způsobem (i když Linus má pochyby, že to tak je). Bylo by ale stejně vhodné takový kód opravit; otázkou je, jak to udělat. První možností je provést audit všeho kódu, který používá mutexy, aby se podařilo najít problematická místa, ale to by byla dlouhá a nepříjemná práce – nikdy by se ji asi nepodařilo kompletně udělat.
Alternativa – tedy opravit mutexy, aby se odstranila nebezpečná situace popsaná výše – se zdá být snazší a dlouhodobě robustnější. Ingo Molnar navrhl dva způsoby, jak by se to dalo udělat, oba jsou postavené na tom, že současné používání count a wait_lock k ochraně částí zámku představuje jádro problému. Prvním návrhem bylo odstranit count a předělat wait_lock na speciální spinlock o třech stavech; druhým návrhem je používání count pro řízení přístupu k zámku. Oba způsoby mají potenciál zmenšit velikost struktury mutexu a zmenšit objem kódu specifického pro platformy při současném opravení problému.
V době psaní tohoto textu nebyly zaslány žádné patche. Bylo by ale překvapivé, kdyby se nějaká oprava tohoto konkrétního problému neobjevila do otevření začleňovacího okna verze 3.14. Problémy se zámky se těžko řeší i když mají synchronizační primitiva jednoduché a srozumitelné chování; mít v této vrstvě jádra schované drobné pasti je receptem na spoustu nepříjemností v budoucnosti.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
23.12.2013 17:38
Jardík | skóre: 40
| blog: jarda_bloguje
Běžící blákno, které může takto rychle získat zámek ...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct mutex {
atomic_t count;
spinlock_t wait_lock;
struct list_head wait_list;
};
Jádro pudla je v tomto nižším patře = v kernelovém mutexu.
Všimněte si položky "struct list_head wait_list" - to je nějaký spojový seznam "čekatelů na zámek".
Uvnitř páru volání mutex_lock()/mutex_unlock() existují dvě cesty: rychlá a pomalá.
Pomalá cesta bere spinlock a hraje si s wait_listem (seznam čekajících procesů) = při mutex_lock() se vlákno do seznamu zapíše, při mutex_unlock() se vyškrtne.
Naproti tomu rychlá cesta uvnitř mutex_lock() za příznivých okolností jenom "proletí", nepřidává se do wait_listu = nebere spinlock, pouze si atomicky (s podporou CPU) dvakrát sáhne na položku count. Podobně uvnitř mutex_unlock().
Za příznivých okolností, konkrétně když o mutex soupeří dvě vlákna, a to ještě na konci delší "dávky" soupeřících vláken:
i v případě, že posixová synchronizační primitiva fungují, jak bych čekal. To je tak, když znovu vynalézám kolo, protože si ho chci maličko přitesat pro svoje potřeby...
Jádro pudla je v tomto nižším patře = v kernelovém mutexu.Strucne receno, mutex_lock() v jednom threadu uspeje drive nez skonci mutex_unlock() v druhem a ten druhy stale pristupuje k interni mutexove strukture. Pokud se na takove chovani podivam z hlediska konvencni semantiky posixovych mutexu (tedy pokud by se tak chovali userspace mutexy), tak mi to jako zavadne neprijde (primarni cil - vzajemne vylouceni kodu *uvnitr* mutexove sekce - je zajisten), akorat mutex_destroy() by musel vzit spinlock a tim se ujistit, ze paralelni mutex_unlock() uz skoncil. To by mohlo byt i adekvatni reseni pro kernelove mutexy.
R.
delete kdekoliv mimo destruktor smart pointerů pokládám za velmi špatný kód* a race conditions dealokací opět dobře řeší smart pointery používající atomický reference counter. Zde je to zesložitěné tím, že se tam snaží aktivně spouštět jiné vlákno, ale s něčím takovým se v user space setkáte jen výjimečně.
* Schválně za jak dlouho přijdete na to, že tohle leakuje?
class Socket
{
public:
Socket()
{
if (!connect())
throw std::exception();
}
bool connect()
{
return false;
}
};
class Test
{
public:
constexpr size_t BUF_SIZE = 4096;
char *buf;
Socket sock;
Test()
: buf(new char[BUF_SIZE]())
{}
~Test()
{
delete[] buf;
}
}
Chápu, že to omezení na destruktor strong pointerů je součást nějakého programátorského postupu, jak dosáhnout "vzájemně zaručeného zničení". Nicméně mi to i tak přijde trochu nekompletní, pokud do věci vstupují výjimky...
sock), tak se nezavolá tělo destruktoru; nakonec to je logické, objekt se ještě nevytvořil, a tak není co ničit. C++ v takovém případě volá destruktory všech již zkonstruovaných členů a předků (pokud by Test měl předka, tak jeho destruktor se zavolá), zde tedy program zavolá destruktor buf, jenže to je char *, který se sám nedealokuje. Pokud by buf byl smart pointer, tak jeho destruktor tu paměť uklidí.
S výjimkami není problém, pokud dodržujete RAII, tedy že každý zabraný zdroj má vlastní „hlídací“ objekt, který jej v destruktoru uvolní. A tohle pravidlo právě vede k tomu, aby delete používaly akorát smart pointery (a výrazně zjednodušuje hlídání zdrojů oproti C ).
Ještě bych dodal, že existuje druhé pravidlo, a to že destruktor nemá vyhazovat výjimky, pokud je volán při zpracovávání výjimky (na rozdíl od toho, co méně zkušení programátoři často tvrdí, tak jinak může a dokonce by i měl, pokud třeba selže flush bufferu, tak se asi nepodařilo zapsat data, což by se program měl dozvědět, ale pokud je objekt ničen při zpracování výjimky, pak se stalo něco, co rozhodilo vyšší vrstvu a vzniklé problémy jsou velmi pravděpodobně zavlečené). To jde ale naštěstí vyřešit celkem snadno takto:
~Test()
try {
⋮ // Volání funkcí, které mohou vyhodit výjimku, kromě destruktorů — tam by si to měl řešit ničené objekty
} catch (...) {
if (std::uncaught_exception())
// Případně nějaké logování, pokud vás to zajímá
return;
// catch blok, kterým končí konstruktor či destruktor, má implicitní rethrow
}
noexcept, je potřeba to zrušit:
~Test noexcept(false)
8.1.2014 21:05
pavlix | skóre: 54
| blog: pavlix
To je syntaxe ve stylu: „Půjdu na nákup ne.“ To snad museli vymyslet Francouzi.Spíš lidi z Cisca
(no shutdown)
Ale ono zrovna v tomhle případě to je namístě, u drtivé většina destruktoru je noexcept vhodný.
8.1.2014 23:42
pavlix | skóre: 54
| blog: pavlix
delete jsem od té doby, co delete u kódu, který spravuji, smí používat jen smart pointery, neviděl.
Jádro není v C++ hlavně proto, že v roce 1991 byla podpora C++ dost mizerná. A taky proto, že v jádře bývá problém s implementací výjimek a RTTI, tak se to tam nepoužívá, čímž se C++ snižuje na C with classes. A to už pak rovnou jde psát v C.
takže je mutex odemčený, a přitom o sobě ví, že je používán Odhaduji, že je to dobré spíš pro kontrolu chyb (pthread_mutex_destroy() vrátí v tomto stavu chybu) než k nějaké optimalizaci rychlosti.
Nakonec asi nejvíc optimismu mi vlévá do žil jedna poznámka v linuxové manuálové stránce pthread_mutex_init():
http://linux.die.net/man/3/pthread_mutex_init
Hledejte kapitolu Destroying Mutexes. Je tam kus zdrojáku, který přesně odpovídá našemu problému "poslední zhasne". A tvrdí se tam, že posixové mutexy jsou vůči tomuto stylu zrušení a dealokace odolné. Ještě mě napadlo, mkrnout se do zdrojáku pthread_mutex_destroy(), jestli je tam nějaký extra low-level zámek nebo kontrola - není, prostě se jenom zkontroluje user_count mutexu, bez zamykání. Takže je asi jinde zajištěno, že hodnotě user_count se dá věřit ve vztahu k bezpečné dealokaci. Popravdě řečeno pthread_mutex_destroy() tuto kontrolu provede pouze jednou, a pokud není splněna, vrátí chybu - ale vzorový zdroják v manuálové stránce ani nehlídá návratovou hodnotu pthread_mutex_destroy(), takže teoreticky předpokládá jistotu, že po návratu pthread_mutex_unlock() už žádný opozdilec s mutexem nefidlá (pokud jsme k tomuto závěru došli na základě našeho externího uživatelského reference countu).