Vlákno názorů k článku
Red Hat pracuje na opožděné kontrole podpisu modulů kvůli větší rychlosti bootu od oss - To neznie prave bezpecne.

Předpokládám, že tohle bude ošetřené.

> Předpokládám, že tohle bude ošetřené.
A taiksto predpokladate, ze v tom osetreni nikdy nebude ziadna chyba ani diera.

Předpokládám, že tohle bude ošetřené.
Opravuji, asi to nijak ošetřené nebude. Nechal jsem se unést zdejší debatou o nebezpečnosti. Když jsem se na ten příspěvek podíval, evidentně se počítá jenom s variantou, že už byla integrita modulů ověřena např. pomocí secure bootu. Takže ošetřené to v tuto chvíli asi nijak nebude, protože to není potřeba – patch se zaměřuje na situace, kdy je kontrola podpisů modulů redundantní, takže její odložení nemůže bezpečnost zhoršit.

Takže jsme zpátky u toho, co psal Michal Kubeček. Máme tady novou featuru, kterou je možné použít bezpečně jen když ji není třeba použít vůbec. :D

No, jedna věc je integrita bezpečnostní a tu zajistí secure boot. Druhá je chybová (nějaký bitflip nebo tak) a ta se provede později.

A třetí je politika.. třeba by návrh na kompletní odstranění kontroly neprošel přes maintainery.

V idealnim svete, kde vse funguje jak ma by to mohlo byt pravdive, ale ukazte mi programatora, co nedela chyby :D Ono i te implementaci secure bootu muzou byt chyby. Redundantni a na prvni pohled zdanlive zbytecna kontrola v takovych situacich muze pomoci odhalit problem drive... nez po par minutach, kdy konecne nastartuji vsechny sluzby.

Takhle fungují alarmy – v domech, autech, v bankách… A asi to funguje, když se to používá. On totiž často ten čas je potřeba.

Dovedu si představit, že se odloží třeba aktivace sítě, připojení disku s daty nebo start služeb až po kontrole podpisů modulů. Takže případný útočník by byl v prostředí, kde nic nezmůže.

Alarm v dome nefunguje tak, ze by v case zakodovani slo vlezt do domu klidne oknem v prvnim patre. Definuji se typicky nejaka vybrane zpozdene zony v okoli klavesnic u vstupu, kde je ponechan cas na odkodovani (a rozhodne clovek nesmi opustit prostor zpozdene zony). Ostatni zony spusti ten alarm hned... A rozhodne jde cela EZS postavit i tak, ze odkodovani zastrezeneho prostoru se cele odbude zvenci (zvlaste s moznostmi, co jdou dnes), pak i potreba zpozdene te zony zcela odpadne.

Cemu pomuze, ze odlozim kontrolu modulu, kdyz soucasne budu vazan tim, ze nesmim aktivovat sit, pripojit svazek...? Ten cas tomu beztak venovat nakonec musim... a jen kvuli honbe za par milisekundama v jedne fazi bootu ten problem proste jen "odsunout" jinam na pozdeji a za cenu, ze tam v mezicase naopak nejaky problem vzniknout muze je proste divny a nejak postrada logiku... nejbezpecnejsi je to overovat hned pri natazeni. Ve zpravicce se navic pise, ze to chteji resit prave az ve chvili, kdy nabehne userspace... takze to okno muze byt klidne hodinovy.

Alarm v dome nefunguje tak, ze by v case zakodovani slo vlezt do domu klidne oknem v prvnim patre.
Přesně takhle alarm funguje. Když je alarm zakódován, nebrání zloději, aby vlezl do domu/bytu kudykoli. Alarm zareaguje teprve po té, když je zloděj uvnitř. Nebrání to vniknutí dovnitř, ale slouží to k tomu, aby to zloděje pokud možno odradilo (proto se prvky alarmu jako sirény umisťují viditelně a proto bývá viditelně umístěná informace o tom, že je objekt střežen), a když už to zloděje neodradí, aby mu alarm nedal čas něco ukrást, protože bude muset rychle zmizet.

Cemu pomuze, ze odlozim kontrolu modulu, kdyz soucasne budu vazan tim, ze nesmim aktivovat sit, pripojit svazek...? Ten cas tomu beztak venovat nakonec musim... a jen kvuli honbe za par milisekundama v jedne fazi bootu ten problem proste jen "odsunout" jinam na pozdeji
Zpožděná kontrola se může dělat paralelně s jinými činnostmi. Takže celkový čas startu se zkrátí, protože kontrolu podpisů odstraníte z kritické cesty a provedete ji paralelně vedle nějaké jiné činnosti.

za cenu, ze tam v mezicase naopak nejaky problem vzniknout muze
Předpokládám, že to bude řešené tak, aby podvržený modul nemohl tu kontrolu podpisů vypnout nebo obejít.

nejbezpecnejsi je to overovat hned pri natazeni
Ano, je to nejbezpečnější. Ale někdy není potřeba největší bezpečnost a vyplatí se zanedbatelné omezení bezpečnosti vyměnit za něco jiného (třeba rychlejší start).

Ve zpravicce se navic pise, ze to chteji resit prave az ve chvili, kdy nabehne userspace... takze to okno muze byt klidne hodinovy.
Kde trvá start linuxu hodinu? A i kdyby – pokud během té hodiny nebude mít útočník prostředky, jak škodit (např. nebude dostupná síťová komunikace), je jedno, jak dlouho ta doba trvá.

> Předpokládám, že to bude řešené tak, aby podvržený modul nemohl tu kontrolu podpisů vypnout nebo obejít.

Z čeho tak usuzujete? Dovedete si představit, jak by to technicky vypadalo? Kernelové moduly běží se stejným oprávněním jako kernel sám a mohou mu číst a zapisovat kamkoliv do paměti. Dovedu si představit, že to bude opruz, ale asi ne větší opruz než praktické zneužití buffer overflow.

Z čeho tak usuzujete?
Z toho, že jinak by to nedávalo smysl.

Jestli se nemýlím, už v souvislosti s bezpečnostními moduly se vyřešilo to, že samotné jádro je rozdělené na (minimálně) dvě vrstvy, přičemž některé privilegované operace nemohou provádět běžné moduly.

Kernel a moduly kernelu bezia v ring 0. To oddelenie ktore spominate je ze drivery a software ktory potrebuje pristup k IO operaciam bezi v ring 1 alebo 2. Userspace je ring 3. Ak bude v ring 0 az 2 zavedeny infikovany kod, tak to co citate z disku v ring 3 nemusi byt absolutne zhodne s tym co sa na disku v skutocnosti nachadza...

Jestli některé moduly běží v ring 1 nebo 2, tak to možná smysl dávat bude.
Ale pořád tu vidím otazníky, které tu v diskuzi zazněly jinde:

* Kolik času se tím reálně ušetří? Budu počítat optimistickou situaci, která odpovídá tomu, že ušetříme celý čas kontroly, protože se provede ve chvíli, kdy se CPU fláká. Ověření podpisu je v podstatě hash (dat, která stejně musejí být v RAM) plus ověření podpisu hashe, někdo to tu už odhadoval na řádově milisekundy, já bych taky nečekal víc.
* Scénář se secure bootem (uvádí nejen zprávička, ale i autor v LKML) dává smysl napůl – tady by šlo kontrolu úplně vynechat.
* Proti úspoře stojí navýšení komplexity kódu, která přidává možnost zranitelností (ledaže je kontrola zbytečná, jako v předchozím bodě). Do attack surface spadají i všechna volání API kernelu, které může modul provést před ověřením.

Tak nějak tuším, že RH k tomu má nějaký důvod, ale naprosto ho tam nevidím.

V commitu je zmiňován secure boot, takže s jiným scénářem se v tuto chvíli pravděpodobně nepočítá. Tím pádem kód není nijak složitý a kontrola je v podstatě zbytečná. Následná kontrola je v podstatě jenom ověření, že se chyba nestala někde jinde. Attack surface je tedy v podstatě nulový.

V e-mailu s commitem se píše „significantly improve the boot speed“, takže já věřím, že to mají zjištěné a že to v některých scénářích pomůže.

Tady je to samozřejmě vytažené jako zajímavost, takže to nemusí být nijak častý případ a je klidně možné, že se nikdo z nás, kdo tady diskutujeme, nesetká se situací, kde by to pomohlo. Ale psát rovnou „mně to nepomůže, takže je to k ničemu“ je poněkud nafoukané (a to není na vás, jsou tu jiní takoví experti).

Ano, u modulů ověřených jinak je ten attack surface v podstatě nulový, ale tam moc nechápu, proč nevypnout tu kontrolu úplně. (Samozřejmě jen pro tyto moduly, resp. dokud nejde moduly zavést i jinak.)

tam moc nechápu, proč nevypnout tu kontrolu úplně
Předpokládám, že proto, že v initrd mohou být jen některé moduly nutné pro start jádra a připojení hlavního systému. Ty jsou tedy ověřené, ale zbytek (moduly na hlavním filesystému) secure bootem zajištěné nejsou.

Psal jsem „Samozřejmě jen pro tyto moduly, resp. dokud nejde moduly zavést i jinak.“. Tedy během bootu by to bylo bez kontroly, pak by se zapnula. Ostatně podobně je to v popisu toho patche:

> the kernel waits until the userspace communicates to start checking signature modules.

Ale vždyť to je to, co ten patch dělá. Během initrd bootu se validace podpisů neprovádí, začne se provádět až s userspace.

Aha, ona většina popisu patche šla pochopit oběma způsoby (kontrola provedená později vs. dočasně vypnutá kontrola), nicméně z „This patch introduces a feature to skip signature verification during
the initrd boot phase.“ jsem pochopil, že se kontrola těch modulů z initrd opravdu vypíná.

Ale autor zprávičky to zjevně pochopil též špatně:

> Podpisy u jaderných modulů se zkontrolují zpožděně až naběhne userspace.

Tady už zhruba rozumím motivaci. Resp. stále nevím, kde přesně to něco reálně ušetří, ale aspoň chápu, že na slabém HW to nějaký přínos mít bude a že nejde o nějaké dramatické zvětšení možnosti chyb.

No kdyz se do toho patche skutecne pozorne podivate, tak ten prostor pro chyby tam je velky. Ona ta kontrola se nereaktivuje sama od sebe (Furthermore, a supplementary method is necessary to reactivate verification subsequently), ale musi k tomu z userspace prijit nejaky pokyn. A samozrejme i v tehle casti muze vzniknout chyba, flag v sysfs se z jakehokoliv duvodu nezmeni... a oopss... najednou se nekontroluje nic :-)

To samozřejmě ano, nicméně:

1. Na úrovni samotného kernelu tam dramatické riziko chyb nevidím.
2. V initu je potřeba pohlídat správné zpracování chyb, zejména se nesmí za žádných okolností stát, že boot pokračuje bez toho přepnutí – ať už protože failne něco před přepnutím a skončí skript, nebo protože failne samotné přepnutí. Je na to potřeba dát pozor, ale přijde mi to celkem řešitelné. Rozhodně bych to bral jako řádově menší riziko než snahu o dočasný běh neověřeného kernelového modulu s omezeným oprávněním.

No, jasne... to si kdysi jinde rikali taky :-) Ano, zdanlive to trivialni je, naprogramovat to ted je jedna vec, ale to ze po case nejaky commit muze jinde zcela nepozorovane rozbit je vec jina... takovejch chyb pamatuje historie uz spoustu.

Lenze z kodu modulu natiahnuteho do RAM tak aby ho bolo mozne spustit ten podpis neoverite. Jedine ze by neobsahoval priame volania a skoky. Musite ho nacitat znovu z disku a overit ho proti tomu ako vypadal pred realokaciou.

No, z pohladu komunity tam ani ja nevidim dovod.

Ale pozor, KONSPIRACIA:
Odpoved z helpdesku: No chcete bezpecnejsi system... AIX ste uz skusal? :D

18. 9. 2023, 10:30 editováno autorem komentáře

Napriklad z toho, ze sa nenacitavaju nahodne moduly, ale iba moduly z podpisaneho a overeneho initramfs. Pokial je niekto schopny podpisat initramfs so skodlivym modulom, co mu zabrani podpisat aj samotny skodlivy modul?

Vsak take ulohou alarmu neni explicitne zabranit zlodeji vniknout dovnitr a nikde jsem nenapsal, ze to jeho ulohou je. Ulohou alarmu je.... spustit alarm, treba vc. notifikace na PCO, ktery obratem aktivuje vyjezd bouchacu, co tomu zlodeji rozbiji drzku...

Ulohou kontrol pri natahovani kerneloveho modulu je zabranit natazeni nezadouciho kodu, zpravidla s velmi vysokym opravnenim. Ta ochrana tu je a funguje... jen nejakym z prominutim posukum se se zda, ze to trva moc dlouho. I kdyz se realne resi par milisekund.

Z pohledu optimalizace procesu bootu co resi RH se resi naprosta marginalnost, kde zpozdeni je minimalni. Jasne, nejaky vyvojar z si vykaze cinnost, ale za cenu toho, ze bezpecnost celeho retezce to bez pochyb snizi. Zanedbatelny je tady prave cas, ktery ta kontrola zabere.

Kde trva start hodinu? Treba u velkych databazi. Ale chapu, ze od vyvojarskyho stolu se zkusenosti z realneho provozu nahani dost blbe... protoze to byste takovou ptakovinu, jak dlouho trva kontrola zrovna tech signatur kernelovych modulu neresil.

Takže evidentně se zabezpečení dá řešit i tak, že se nesnažíte útočníkovi zabránit v útoku, ale snažíte se útok detekovat a útočníkovi zabránit v pokračování útoku.

Z pohledu optimalizace procesu bootu co resi RH se resi naprosta marginalnost, kde zpozdeni je minimalni.
Jasně, v RedHatu o tom nic neví, zapomněli se vás zeptat.

Kde trva start hodinu? Treba u velkych databazi. Ale chapu, ze od vyvojarskyho stolu se zkusenosti z realneho provozu nahani dost blbe... protoze to byste takovou ptakovinu, jak dlouho trva kontrola zrovna tech signatur kernelovych modulu neresil.
Běžte s tím trollením už do háje. Psal jste, že hodinu trvá, než se start systému dostane do userspace. Vám se databáze startuje v kernelu? Na to jste přišel v reálném provozu?

Resit kyberbezpecnost timhle zpusobem je tak trosku diletanstvi. Zvlast pokud se bavime o par usetrenych milisekundach. A ano, ze v korporatech sedi spousta lidi, co u podobnych ptakovin vykazuje cinnost neni nic duverneho. A to, ze ve velkem korporatu neco vymysli opravdu neimplikuje, ze to je spravny postup.

Ona ta kontrola behem uz natazeni ma svuj padny duvod.... nejdriv cely kod s plnou paradou spustit a pak nekdy s odstupem casu prekontrolovat kontrolni soucty je proste blbost uz v samotnem navrhu.

Máte pořád pocit, že tohle se nutně dělá pro serverový trh.

Nenapadlo Vás třeba, že existují i jiná nasazení?

Embedded, automotive, Telco. Tam ta kontrola nemusí být pár milisekund (nižší výkon, chybějící akcelerace), secure boot je často zapnutý a restart po výpadku musí být co nejrychlejší, aby (v extrémním případě) fungovaly třeba blinkry.

Od té doby co jsem viděl plnotučný linux v GPS přijímači ve formě SMD čipu, včetně nožičky s funkcí ATX power tlačítka, mě takové nápady nijak nepřekvapují.

Ono je jedno, v cem to nasazujete. Tenhle pristup "jupi, usetril tady jsem par milisekund" bude presne misto, na ktere se utocnici pak zameri a tehle slabiny nalezite vyuziji ve svuj prospech. Jen proto, ze nekdo nedomyslel dusledky...

A zrovna automotive je oblast, kde s bezpecnosti na stiru jsou. Vytvaret nove problemy namisto reseni tech, co tam uz dnes jsou je cesta do pekel... zkratkou.

Jen proto, ze nekdo nedomyslel dusledky...
To, že vy se v problematice neorientujete, takže nedokážete domyslet důsledky, neznamená, že je nedokáže domyslet někdo jiný, kdo se v tom orientuje.

U modernich cipu pro embedded uz nizsi vykon neni argument. Tim spis ze pro embedded je jadro i s moduly hodne osekane. A klidne si obcas muzete dovolit postavit jadro bez modulu jako monolit.
Kolikrat vam takovy linux taky bude bootovat? Nebude treba v deep sleep a neprovede se plny boot jen kdyz treba vymenite baterku v aute?

Ten GPS prijimac... linux asi nebyl primo v GPS casti radia ze? Tam musel byt aspon nejaky hardRTOS.

Byl přímo v GPS části. On linux je překvapivě celkem slušně real-time i bez pre-emptivních patchů.

Elektrické prostředí v autě je tak brutální, že musíte počítat s rebootem kdykoliv.

Jasne, takove tlumeni tocny v kloubovem autobusu se muze restartovat kdykoliv si vzpomene... no to by to vypadalo... :-)

Jistě, že může. Klasická průmyslová smyčka má reakční dobu cca 1 ms nebo více. Pokud minimalizujete dobu restartu, tak si toho to zařízení ani nemusí všimnout.

Krom toho, tlumení točny asi nebude ovládáno primární řídící jednotkou napřímo.

Viděl jste někdy co dělá elektrická síť v autě při startu? Tam rozhodně není regulovaných 12 V.

Vsak samotny linuxovy kernel vam za 1ms nenabootuje... ani omylem... :-) Ohanet se timhle pri obhajobe toho nesmyslu z RH je tak trosku chucpe... Za ridici jednotku tocny v autobuse si muzete zamenit treba ridici jednotku airbagu - to je jedno, jsou mista kde restart "behem jizdy" je zcela nemyslitelna vec, narozdil od nejakeho infotainmentu. Co dela napeti v palubni siti vim, ale zrovna osetrit tohle je trivialni task, co zvladne i zacinajici elektronik a zvladne to i levna cinska nabijecka, co vam posila 5V do telefonu kvuli nabijeni. Mimochodem, jak byste se tvaril, kdyby v pripade kolize airbagy nebouchly jen proto, ze se palubni napeti zrovna zhouplo, kernel zpanikaril a system znovu startoval....? ;-) No mozna by vam to uz bylo pak jedno, ono v hrobe uz toho clovek moc neresi, ze...?

Resit kyberbezpecnost timhle zpusobem je tak trosku diletanstvi.
Není, je to jeden z běžných způsobů.

Zvlast pokud se bavime o par usetrenych milisekundach.
To tvrdíte vy.

Ona ta kontrola behem uz natazeni ma svuj padny duvod.... nejdriv cely kod s plnou paradou spustit a pak nekdy s odstupem casu prekontrolovat kontrolni soucty je proste blbost uz v samotnem navrhu.
Tak nám ten důvod vysvětlete pro scénář, který je uveden v e-mailu s commitem – tedy v prostředí secure bootu.

A secure boot je bez chyb... tak ted nam tu povezte jeste tu O Cerveny Karkulce, pane Jirsak... kdyz jste u tech pohadek :-)

Tak muze si to napsat do CVcka ;-) Cili alespon nekomu k necemu to je.

asi ti uniklo na co sem reagoval a i unikl tvuj argument vejs...

Ratbatcat psal ze par sekund je u 10000 server par hodin
- to by bylo jen pokud se startovali postupne vsechny
- sam pises ze najednou je nebude vypinat, tzn. je najednou nebude ani zapinat
- navic nahore "navrhujes" ze nez se moduly opozdene zkontroluji nemuseli by mit dostupnou sit, disky, sluzby = kde je pak to zrychleni kdyz sluzby bydou dostupne po stejne dobe jako kdyz se moduly kontroluji rovnou?

shrnuto: mozna je nekde schovana vyhoda, ale na prvni pohled zadna neni, aby odlozeni bylo bezpecne musi se odlozit nasledne veci, takze se cas neusetri

to by bylo jen pokud se startovali postupne vsechny
Ale Ratbatcat nepsal, že je to pár hodin souvislé doby. Je to pár hodin výpočetního výkonu serverů, kdy ty servery mohly dělat něco, proč se jejich provoz platí.

kde je pak to zrychleni kdyz sluzby bydou dostupne po stejne dobe jako kdyz se moduly kontroluji rovnou?
Nebudou dostupné po stejné době. Ta opožděná kontrola podpisů se evidentně dělá proto, aby neblokovala start, ale bylo ji možné provést ji paralelně s jinými činnostmi. Je to stejný princip, jako když se služby po startu nespouštějí jedna po druhé, ale spouštějí se paralelně v závislosti na tom, když mají splněné své závislosti. Doba startu jedné služby se tím nezmění, ale zkrátí se tím doba mezi startem userspace a spuštěním všech služeb – protože start některých služeb běží paraleleně, jejich start se tedy časově překrývá.

Neusetrite tym ziadny strojovy cas. To ze sa tie moduly skontroluju az v userspace tiez zaberie nejaky strojovy cas, ktory bude vecsi nez keby sa to kontrolovalo v kernel space. Ak si myslite ze v userspace ta kontrola prebehne rychlejsie, nez v kernel space, tak chodte edukovat vyvojarov samby v kernel space... A ak uz tolko chcete usetrit peniaze zakaznikov za spaleny strojovy cas, tak radsej rozjimajte nad tym kolko sa na mnohych servroch zbytocne premrha strojoveho casu a pamati, pretoze nejake pako tu servrovu aplikaciu napisalo v jave alebo v dotnet, ci v inom interpretri...

Ak si myslite ze v userspace ta kontrola prebehne rychlejsie, nez v kernel space, tak chodte edukovat vyvojarov samby v kernel space...

Tam je trochu jiná situace a v jádře to opravdu může být efektivnější, protože odpadne režie syscallů. U ověření podpisu modulu není žádný důvod, proč by měla být jedna nebo druhá varianta výrazně rychlejší, pokud není výrazně efektivnější jedna nebo druhá implementace kryptografických algoritmů.

Za cenu podstatneho snizeni bezpecnosti. Kontrolni podpis tam neni pro srandu kralikum, ale prave proto aby se zamezilo spusteni kodu, ktery se spustit nema. Jirsakuv pristup "jejky, se spustilo neco co nemelo, panika" za tech par usetrenych milisekund fakt nestoji. Ono v tom mezicase, nez se neco spusti a nez probehne ta userspace kontrola se muze s vyuzitim nejakych technik stat i to, ze takto spusteny kod uz tak snadno nedetekujete.

Ak si myslite ze v userspace ta kontrola prebehne rychlejsie, nez v kernel space, tak chodte edukovat vyvojarov samby v kernel space...
Nemyslím. Jasně jsem napsal, že výhoda toho odložení je paralelizace. Už jsem to tu vysvětloval dvakrát, potřetí už to vysvětlovat nebudu.

A ak uz tolko chcete usetrit peniaze zakaznikov za spaleny strojovy cas, tak radsej rozjimajte nad tym kolko sa na mnohych servroch zbytocne premrha strojoveho casu a pamati, pretoze nejake pako tu servrovu aplikaciu napisalo v jave alebo v dotnet, ci v inom interpretri...
Provozovateli cloudových serverů je jedno, že zákaznický software mrhá strojovým časem – naopak je rád, dostane to zaplaceno. Naopak ale není rád, když tím strojovým časem mrhá při bootu a žádný zákazník mu za to nezaplatí.

Mimochodem, strojový čas a paměť jsou mnohem levnější, než práce programátora a než oprava chyb. Takže to, že je to napsané v interpretovaných jazycích, to zlevňuje (resp. to vůbec umožňuje, aby ty aplikace vznikly – věci jako Google nebo cloud by v assembleru nikdo nenapsal). Mimochodem, ten interpretovaný kód může ve výsledku běžet i rychleji, než nativní kód – protože interpretovaný kód se často za běhu překládá do nativního kódu, a přeloží se přímo pro danou architekturu a pro daný typ zátěže, tedy může být lépe optimalizovaný, než generický překlad.

Jasne, kazdy prevadzkovatel checkuje server (virtual) ci uz nabehol do userspace a az od toho okamihu zacne uctovat :D

Zamyslel ste sa niekedy nad tym, kolko casu zbytocne stravite ohybanim svojho virtualneho vesmiru tak aby sa mohol ostatnym zdat realny? Nadany clovek by ten cas pretavil na nieco uzitocne...

Jasne, kazdy prevadzkovatel checkuje server (virtual) ci uz nabehol do userspace a az od toho okamihu zacne uctovat :D
Samozřejmě. Protože provozovatel třeba SaaS účtuje za dobu, kdy běží nějaká služba, třeba databáze. Provozovatel kontejnerových služeb účtuje za dobu, kdy běží kontejnery. Provozovatel virtualizace účtuje za dobu, kdy běží virtuální počítače. Všechny tyhle věci se spouští na serveru provozovatele až z userspace.

Zamyslel ste sa niekedy nad tym, kolko casu zbytocne stravite ohybanim svojho virtualneho vesmiru tak aby sa mohol ostatnym zdat realny?
Já doufám, že to vám a případně ostatním pomůže, když se dozvíte, jak to funguje v reálném světě.

Z reakcii ostatnych uzivatelov na vase prispevky usudzujem, ze si myslite ze ste jediny kto zije v realite, ostatny podla vas nemaju ani tucha jak to v realite vyzera, vsak... nezufajte dnesny doktori by si mali vediet poradit...

Este raz, pomaly a naposledy: ak sa bude kontrola modulov riesit az v userspace, tak ju spomalia syscaly, overenie opravneni, znovunacitanie modulov len koli kontrole a dalsie zalezitosti ktore pri kontrole v kernel space odpadaju. Vo vysledku teda budete mat o malo rychlejsi boot ale spomalite si tym nabeh stroja do produkcneho stavu. Na paralelizaciu nespoliehajte. Systemd nabieha paralelne, takze tazko najdete jadro procesoru ktore by len tak lezalo ladom... K tomu si pridajte bezpecnostne problemy, secure boot vam zaruci len podpisane initrd, tam vsak mate len zakladnu sadu modulov, takze nie vsetky moduly ktore jadro nacita budu podpisane v ramci secure bootu. A infikovany modul moze zkreslit kontrolu z userspace tak, ze sa bude vzdat vsetko v poriadku.

Z reakcii ostatnych uzivatelov na vase prispevky usudzujem, ze si myslite ze ste jediny kto zije v realite, ostatny podla vas nemaju ani tucha jak to v realite vyzera, vsak... nezufajte dnesny doktori by si mali vediet poradit...
Ne, v realitě žije většina lidí. Ale je tady pár lidí, kteří si myslí, že realita je pár jejich serverů a nic jiného neexistuje.

Este raz, pomaly a naposledy: ak sa bude kontrola modulov riesit az v userspace, tak ju spomalia syscaly, overenie opravneni, znovunacitanie modulov len koli kontrole a dalsie zalezitosti ktore pri kontrole v kernel space odpadaju. Vo vysledku teda budete mat o malo rychlejsi boot ale spomalite si tym nabeh stroja do produkcneho stavu.
Nemusíte to vysvětlovat ještě jednou, když už jsem vám to vyvrátil. Vysvětloval jsem tu několikrát, že jádro na to ověření podpisů čeká a nic jiného dělat nemůže, zatímco v userspace se to ověření může provádět paralelně s jinými operacemi.

Navíc je nesmysl to vaše tvrzení o syscalech a kontrole podpisů z userspace. Asi jste nepochopil, co ten patch vlastně dělá. Ten patch dělá to, že (když je aktivován příslušný příznak) nebude jádro kontrolovat podpisy modulů. Userspace pak zápisem do /proc tu kontrolu podpisů v jádře zapne. Takže jediný přechod navíc mezi jádrem a uživatelským prostorem je ten jeden zápis příznaku, který v jádru aktivuje ověřování podpisů, které bylo vypnuto. To fakt není něco, co by start systému zpomalilo.

Na paralelizaciu nespoliehajte.
Já na ní spoléhám. Spoléhá se na ni ve spoustě jiných případů a pomáhá to.

Systemd nabieha paralelne, takze tazko najdete jadro procesoru ktore by len tak lezalo ladom...
Při startu služeb nejde jen o CPU, ale také o čtení z disku, ze sítě… Při ověřování podpisů nejde jen o CPU, ale také o čtení z disku. Vaše představa, že při startu userspace jedou všechna jádra na plno, se ve většině případů nebude shodovat s realitou. Tipoval bych, že většinou se bude čekat na disk nebo na síť.

K tomu si pridajte bezpecnostne problemy, secure boot vam zaruci len podpisane initrd, tam vsak mate len zakladnu sadu modulov, takze nie vsetky moduly ktore jadro nacita budu podpisane v ramci secure bootu. Právě proto to není vypnutí kontroly podpisů, ale její odložení. Taky už se to tu psalo asi stokrát.

1. Načte se jádro a moduly z initrd v rámci secure bootu, podpisy u modulů se nekontrolují.
2. Řízení se předá userspace.
3. Z userspace se aktivuje ověřování podpisů modulů.
4. Přimountuje se souborový systém s dalšími moduly.
5. Při načítání dalších modulů se kontrolují podpisy.

Tak, a teď můžete společně s Dannym mudrovat nad tím, kde tam je ta díra umožňující nahrát nepodepsaný modul. Jasně, je možné kroky 3 a 4 omylem prohodit. Ale není tak těžké spustit je ve správném pořadí a s krokem 4 počkat až na okamžik, kdy byl proveden krok 3.

Výhoda, kde se to uplatní, je třeba kexec.

"start serveru neproduktivní doba."

Co cekat od Jirsaka, ten totiz nikdy zadny server nevidel ani z rychliku. Jirsaku, jen kontrola HW a jeho inicializace muze trvat klidne 1/2 hodiny. Jestli bude kernel startovat o sekundu rychlejs je uplne irelevantni.

Nemluve o tom, ze se ty servery klidne i najednou vypnou, presne v okamziku, kdy zafunguji ty veci o kterych nemas paru, jako treba vypadek napajeni a UPS.

jen kontrola HW a jeho inicializace muze trvat klidne 1/2 hodiny. Jestli bude kernel startovat o sekundu rychlejs je uplne irelevantni.
Tady řádí nějaká nemoc postihující logické uvažování? Už několikátý člověk tady argumentuje „existují případy, kdy to nepomůže, tudíž je to k ničemu“. Takže zrušíme v autech pásy a airbagy, protože jsou případy, kdy nepomůžou? Zrušíme zámky na dveřích, protože někdy nefungují?

Takže znovu – podstatné není to, že to někde nepomůže, podstatné je to, že to někde pomůže. Třeba v embedded zařízeních inicializace hardware proběhne rychle; naopak tam není velký výkon, takže výpočet hashů může trvat poměrně déle.

Nemluve o tom, ze se ty servery klidne i najednou vypnou
To je z hlediska doby startu serveru relevantní zhruba jak?

Jenze vy tady naopak sam klidne akceptujete stav, kdy airbag je na chvili zcela vypnuty jen proto, abyste teoreticky mohl byt v cili o par milisekund driv ;-) Kdyz uz jste u tech primeru...

Danny, 12:43: Nikoli.

Dojde v podstatě k vynulování času při rebootu, třeba kvůli novému jádru, kdy se využívá kexec. To je velmi zásadní i pro mne, protože si toho nikdo nevšimne.

Zavadece samozrejme ne, ale porad tam vetsi cas zabere vlastni start sluzeb v userspace. A treba i na proxmoxu ten "problik" BIOSu trva dyl, nez natahovani kernelovych modulu s celou kontrolou pak...

Jak dlouho trvá start zavaděče asi RedHat moc ovlivnit nemůže, kontrolu podpisů modulů ovlivnit může. A z hlediska zrychlování startu není zajímavé to, že někde start zavaděče trvá dlouho, podstatné je to, kde to je rychlé. Vaše argumenty znějí, jako kdybyste psal, že je zbytečné, aby Linux podporoval víceprocesorové systémy, protože existují i jednoprocesorové systémy. Ano, existují, ty z podpory více procesorů těžit nebudou. Ale ty víceprocesorové systémy ano. Takže pokud provozujete nějaký enterprise hardware, kde se počítá na minuty nebo desítky minut doba studeného startu, než se vůbec spustí zavaděč systému ze systémového disku, tam tohle vylepšení zajímavé nebude. Tam, kde je tenká virtualizace a prakticky se spouští jenom nové jádro, a v userspace se pak třeba spustí jenom jedna služba, tam to zajímavé být může. Ve vaší praxi se to třeba nebude hodit k ničemu, tak to prostě nebudete používat. Tak jednoduché to je.

I pokud inicializace samotneho enterprise hardware trva hodiny, tak tech par milisekund navic pri kontrole natazeneho modulu, co to ovlada to fakt nevytrhne. A tam kde se pousti jenom jadro a jenom sluzba se nemusi ani natahovat ty moduly.

Ostatne vetsinu balastu si natahuji ruzne auto-detekcni mechanismy, kdy realne pri startu natahujete i moduly co na danem systemu vubec nepotrebujete. Ale ono slepit initrd tak, aby tam ten zbytecny balast nebyl je uz moc prace, tak se vymejsli blbosti okolo, ze? :-)

Dobre. Tak v druhe casti spektra v embedded mi to taky smysl nedava... kde to tedy smysl dava?
A pokud bych byl kernel vyvojarem tak tam uz tim tuplem ne kdyz mam uplnou kontrolu nad systemem.
Nesnazi se nam nahodou nekdo dostat do systemu hriste pro backdoor?

Tohle zasvinovani systemu coby kdyby .. mozna to pouzijeme nema pri vyvoji operacnich systemu co delat.

kde to tedy smysl dava?
Přečtěte si diskusi, bylo tu to napsáno mnohokrát.

A pokud bych byl kernel vyvojarem tak tam uz tim tuplem ne kdyz mam uplnou kontrolu nad systemem.
Jenže ten systém tam není proto, aby tam byl samotný kernel. Kernel jenom poskytuje služby něčemu dalšímu, co je ten důvod, proč se ten počítač vůbec provozuje. Kdyby Linux používal přístup „my si tady v jádru děláme, co chceme, a userspace nás nezajímá“, nikdo by ho nepoužíval.