To zní jako zajímavý nový druh Meltdown, až cache/tlb/... cpu nebude mít pod kontrolou jeden kernel.
Na jednotlivém CPU jádře se nestřídá víc kernelů.
Každý kernel má množinu jader vykolíkovanou sám pro sebe.
TLB... není to uvnitř CPU jádra, ještě mimo L1 cache?
Nějaký sideband kanál může existovat jedině v i-cache/d-cache na úrovni, která je sdílená napříč jádry. Toto bude nejspíš L3 cache. Třeba L2 cache bývá sdílená mezi několika málo sousedními jádry v "hnízdě", pokud vůbec. V tom případě riziko zneužití L2 cache k nějakému sideband útoku mezi instancemi lze omezit tím, že přidělím jádra CPU konkrétní instanci kernelu podél hranic "hnízd L2 cache".
1. 9. 2026, 10:01 editováno autorem komentáře
Třeba AMD Genoa, Bergamo a Turin mají “hnízda” až na úrovni L3. Intel v posledních modelech na L2. Je to divočina.
chlapi trochu se uklidnete, pokud maji web vyrobeny pomoci ai jeste furt neznamena, ze jejich kernelovy kod opravdu neni super vec. protoze takovy napad existuje uz delsi dobu a nejen v linuxu.
Díky za tuto zprávičku :-) Zejména oznamovací zpráva na odkazu uvedeném v článku je dost pošušňání = fajn počtení.
Tenhle trik, že se hostitelský OS vzdá nějaké množiny jader, a přenechá je "endoparazitujícímu sousedovi" včetně přiměřené množiny IRQ pro taktéž přenechaná PCI zařízení, to jsem viděl párkrát v "průmyslovém" nasazení. To vnitřní siamské dvojče bývá najaký RToS / exekutiva realtime řídícího systému. Vídám to provozováno v kombinaci s Windows v roli hostitelské instance - NT kernel má zřejmě pro toto systematickou podporu. A mám také určité podezření, že jsem takhle viděl uspořádaný nějaký RAIDový firmware: hostitelská instance Linuxu řešila styk s vnějším světem (management), samotný RAIDový engine byl opouzdřený uvnitř jaksi bokem.
Tzn. tentokrát někdo vytvořil generickou podporu do linuxového kernelu :-) a "spolucestující OS" je jednoduše další instance kernelu...
1. 9. 2026, 10:19 editováno autorem komentáře
ano, v průmyslu se to takhle často rozděluje, např. QNX je na tom založený nebo siemens Jailhouse. Vlastně on takový Xen dom0/domU funguje vlastně stejně.
Líbí se mi podobná cesta (vím, že to je zatím experiment), tenhle projekt už zkouším s nixos.
Já si pamatuju značku jenom z posledního takového setkání - u značky Beckhoff. Nebylo to prvně, ale od koho byl ten soft co jsem viděl dřív už nevím.
Ano, viděl jsem takhle třeba RTX/RTX64 od Interval Zero. Není to duplikovaný další NT kernel, ale odlišné, speciální RT jádro, co se startuje přes Windows ovladač.
Windows samotné mají vyloučená určitá jádra, na která nesahají. Ten ovladač pak při startu zabere exkluzivní blok paměťi pro RTX z non-paged poolu. Tam pak nasype zavaděč a kód RTX. Jako ring 0 ovladač je pak víceméně přes APIC a IPI (inter processor interrupts) schopen probudit ta vyloučená jádra s offsetem na startovací adresu.. (budou tam určitě ještě nějaké další x86 chuťovky, 16 bit real mode atd. ;)). Jsou tam pak samozřejmě i nějaké části paměti vyhrazené na komunikaci a sdílení dat mezi hostitelským systémem a RTX.
Vůbec se nepohybuji kolem průmyslové automatizace, ale s tímhle jsem se setkal u jiných oblastí citlivých na deterministické časování. Audio, video přenosy po síti s použití PTP pro synchronizaci atp. Zpracování audia s nízkou latencí a krátkými buffery.
Akorat to bylo porad hodne sw based kdy s tim securitaci meli vazny problem.
Kdy to nefungovalo tak ridici backplane logika nepropojovala elektricky vybrane moduly jako cpu a i/o boardy a jine.
Virtualizace "bez hypervizoru", ve ktere jen bezi system, ktery spousti dalsi operacni systemy a prideluje jim prostredky? :-)
:-) taky jsem se usmál. No... on to není hypervizor ve smyslu VT-x. Neštudoval jsem, jestli třeba nepoužívá aspoň VT-d / SR-IOV / IOMMU = prostředky pro izolaci/virtualizaci PCI zařízení, které IMO nepotřebují další level překladových tabulek v ochraně paměti (RAM) a tedy nezpomalují CPU... Trochu v těch buzzwordech plavu. Jestli správně čtu oznamovací e-mail, tak konkrétně apicv je uváděn jako součást konfigurace "kontrolní sestavy s klasickou virtualizací", proti které porovnávají = nikoli jako vlastnost využívaná multikernelem.
Nevím zda má multikernel toto vše řešeno "kooperativně"...