Názory k článku
Starý initrd možná na definitivní cestě pryč z jádra

Ja v tom prvnim prispevku teda ctu o vicero block devices... ale budiz :-) Ale v principu tam asi problem nebude, jen si ten svuj edge-case budete muset doscriptovat sam... proste si ten obsah druheho ramfs pripojite jako nejaky loop device (treba?) a dal se chovate stejne, jako kdyby tam byl standardni disk? Porad jsme se nedobrali k tomu, proc by to dle vaseho nazoru nemelo jit.

initrd : append=X jsou prezentovany jako block device (a na nem se zkousi mount z nekolika typu FS, typicky ext234, a zde prave erofs neni uveden.. jinak erofs v jadre je, v kontextu teto zpravicky)

initramfs : append=X je prezentovan jako VFS (je to cpio archiv ktery se rozbali jako "/" a je z nej pak spusten init)

Pokud z jadra zmizi podpora pro initrd, tak nebude uz zadnej block device z tech append= parametru. O to me jde.

A zadnej loop nenajdete - jako z ceho? kdyz akt appendnuti ma na starosti bootloader (a ty casti doda z disku, nebo site, nebo jakkoliv jak se dana vec frikulinsky zavadi).

Nemam ambice resit vas konkretni problem, ale predat "exoticky" setup do initramfs skrze parametry v obecne rovine problem neni, zalezi na scriptech, co tam honite... ja si takhle treba nastavuji bond s LACP a nad nim vlan, aneb dokazu mit v initramfs fuknci networking i v mem pomerne specifickem use-case. Kernel parametry, kterym sam nerozumi proste preda do userspace...

Vy spis absolutne nemate mentalni kapacitu pochopit, ze se tady nepredava command line - ale samotne obri "bloby", ktere jsou proste dalsimi append initrd binarkami.

Ze 99.99% lidem staci jeden initramfs, neznamena, ze neexistuje use case optimalne vyuzivajici soucasne moznosti kernelu tak jak je.

Mohl bys par tech pripadu popsat?

V embedded reseni je v prvnim initrd cely FS s userspace a aplikaci. V druhem je per-device customizace (a la VPD). V pripade updatu konfigurace se meni jen malej konkretni blob.. nemusi se prekopavat a prepisovat velky systemovej image. Sance ze si neuplnou synchronizaci znicite OS je tedy nulova. Storage neni v runtime pouzivan vubec - nehrozi efekt niceni sd karet jak u RPi hracek. Stejny payload jde natahnout z spi flash, skrze usb/seriak, nebo skrze sit. Userspace nic nedotahuje, kernel-init-app. Zadne minutove booty.

Linux nejsou pouze PC desktopy, to vam asi musi byt jasny.. a pokud neni, otevrete oci.

To initrd ale je někde uloženo. Třeba můj starý QNAP má speciální storage /dev/mtd0 až mtd5. A ten první initrd (mtd1) může normálně mountnout ty ostatní. Jsou read only a mimo systém, ale jsou dostupné.

Nezapomínejte, že občas chcete aktualizovat i ten kernel.

2RDa :Že se ti chce něco s ním chce řešit. Já ho osobně považuji za trola stejně jako Jirsáka, cc, apod. Osoba(osoby) za těmito profily zvládají maximálně encyklopedické znalosti a známé obecné postupy ale chtít po nich skutečně hloubkovou znalost či něco skutečně sofistikovaného v problematice která není obecně rozšířená a známá je v zásadě směšné. Fakt sis toho ještě nevšiml?

"cc" má sice občas poněkud extrémnější názory ale srovnávat ho s Jirsákem (který se, mimochodem, v poslední době relativně uklidnil) nebo nedejbože tímhle supertrolem, to je urážka i pro něj.

Každopádně v případě tohohle, ehm, osoby, nejde o znalosti nebo neznalosti ale o nějaký komplex pocitů méněcennosti a bůhví čeho ještě. To je přesně ten typ, před kterého postavíte zelené jablko a on se začne hádat i o to, že je zelené a že je to vůbec jablko a to jen proto, aby shodil všechno co řeknete nebo uděláte. Hádat se s ním neznamená řešit technický stav věci ale jeho osobnostní problémy.

Ty bloby se musi od nekud nacist. O nacitani toho prvniho blobu se stara zavadec (tzn. typicky grub), nikoliv kernel. A fantazii mam dost velkou na to, abych si dokazal high-level predstavit script, co v ramci toho prvniho initramfs dotahne zbytek, co je potreba... at uz je to cokoliv. Uvnitr initramfs je to koneckoncu sada shellovych scriptu, co dela vselimoznou magii.

Tedy proc by mel byt problem v ramci initramfs nacist tech blobu, kolik jen hrdlo raci? Ono je lepsi nektere veci z kernel space presunout do userspace (a z kernelu to proste vyhodit), zvlast kdyz to v tom userspace proste a jednoduse realizovatelne vcelku snadne je. Proc by to mel delat primo kernel?

Kazdy initrd nacte zavadec, nejenom prvni.

Zavadec = PUSH. Je zde vase mylna domnenka ze zavadec to odnekud cte.. necte. On to do pameti tlaci - a odkud, je uplne jedno.

Dalsi procesy ktere jsou pusteny, uz nemaji vysadu obdrzet data sami - delaji PULL.

A v pripade, ze potrebujete neco nekam vynutit, tak je mnohokrat jednodussi to tam proste dotlacit spravne na zacatku.. (a la IPL) nez pak resit kdo se to pta, zda to smi a podobne.

Pokud si myslite, ze nacist blob po spusteni kernelu je easy - tak se podivejte na device tree - proc ho tedy musi resit zavadec, a nemuze si ho initramfs nacist sam, hlavne by vedel ze jaky ma nacist a nemuselo by se varit pro kazdou desku individualni vid.. oh, pockejte.. asi to nejde, co?

devicetree je přece informace pro kernel. A obsahuje i ten storage pro další kroky. initramfs ho nemůže načíst, protože nemá odkud, dokud kernel neinicializuje ta zařízení.

A proc neuznavate to, ze chci dodat jista jina data do systemu. Jednoduse primo dodat (immediate operand). A nechtit resit odkud si to ma precist nebo stahnout nebo jinak ziskat.

Plus - pokud mechanismus pristupu k tem datum zna jen bootloader (a po precteni lze pristup odstrihnout, napr. do dalsiho resetu, a pak bootnout system), tak se bavime o bezpecnem zarizeni. Nechat kernelu a aplikaci pristup k dulezitym vecem neni casto zadouci.

To zavani security through obscurity... pokud mechanismus pristupu ma jakoze znat jen bootloader... a obvykle drive ci pozdeji se najde zpusob, jak tuhle "ochranu" prolomit.

Mechanismu, jak odstrihnout fyzicke medium pro runtime je cela rada. I obycejny single initramfs muze fakticky primo fungovat jako plnohodnotny system se vsim, co je potreba a bez nutnosti videt medium, odkud bylo nactene.

Podle vas je tedy bezpecnejsi mit medium dostupne pod kernelem a userspacem, ktery se ho az nasledne zrekne, nez ho tam nemit dostupne vubec a mit ho odpojene jeste pred tim, nez se do kernelu preda rizeni? Aha..

Bezpecnost ani architektura pocitacu nebude tedy vase silna stranka.

Ale zpet k puvodnimu tematu - pointa initrd/initramfs (ve smyslu IPL) je, ze zadne klasicke medium (na ktere si muzete sahnout) neexistuje. Ne, ze nemusi existovat, ale doslova, ze zadne neexistuje.

A z ceho jste dovodil, ze to zdrojove medium, ze ktereho se initramfs nacte musi byt dostupne pod kernelem? Ujasnete si, jak initramfs funguje. Pointa sdeleni je nicmene ta, ze k pripojeni media muze dojit... i kdyz to nejakym tim umelym klackem (ala obscurity) implicitne neudelate. Zalezi ciste na motivaci utocnika, jestli se ten vas obskuritni zamek pokusi nejak obejit - a ono tam urcite nejaka dira bude, pokud ten vas firmware mj. umoznuje sve aktualizace.

Co nam tu popisujete je spis smutna realita toho, jak se bezpecnost v embedded svete "resi". Presneji receno neresi a ocurava, protoze ty vase hry na schovavanou systemem "neco jineho to nacte do pameti" bez dalsiho rozhodne bezpecne reseni nejsou. Podivejte se na architekturu kolem secure-boot, ta problematika bezpecneho provozu je vyrazne komplexnejsi a netrivialni. No, a nebo ty sve systemy muzete mit ve skutecne read-only pametich, ale to bude i pro vas hadam dost... nepohodlne :) Zatimco vy tu brojite za reseni, ktere je pro vas jednoduche... ale o jeho bezpecnosti tu muzeme dalsi hodiny vest polemiku. Ono jsou to dost casto pekne bastly...

Pokud to ma byt skutecne bezpecne, pak celemu reseni nesmi vadit, ze to medium je nejak dostupne. Pokud to resite jinak, tak se stale bavime o nejake forme obscurity, co se security nic spolecneho nema.

To je jak u blbejch, fakt.

Nevim proc resite bezpecnost, kdyz je tema - moznost nacteni vicero block devices pod initrd, zatimco v initramfs se jednotlive payloady rozbaluji a spousti sekvencne. Oboje ma sve opodstatneni a jen duchem jednodussi lidi jako vy to nevidi protoze nikdy nestaveli neco slozitejsiho nez Ubuntu na svem kompjutru.

Pokud vam NATLACIM do stroje kernel+init sady pres sit nebo konzoli (pres uboot), tak o jakem mediu proboha mluvite??

Bezpecnost resim proto, ze jste ji tu vytahnul vy sam ;-) Vase argumentace stoji na tom, ze tech vicero block devices nacte cosi "tajneho", co kernel jakoze nevidi. A tvrdite, ze proto je to bezpecne :-) Klasicka security through obscurity.

Technicky vzato se i ten initramfs take "natlaci", pokud pouziju vasi terminologii. Vy tu jen frflate, ze to potrebujete mit rozporcovane. Ale ono i s tim initramfs defacto pocita, staci se v tom vami opovrhovane svete podivat, jak se resi treba takove CPU microcode. Kdyz to vezmu ad-absurdum, tak to, jak si ten "initramfs" prostor postavite a jak to do nej natlacite je ciste vas byznys.... mozne je ledacos. Jenom to chce opustit to vase "knuu", ze vam nekdo bori neco, co hromadu let pouzivate.... a pokud vam to echt jo vadi, nic vam nebrani si ten kod odstranovany forknout a udrzovat/backpor­tovat, kdyz uz si svuj zivot bez initrd predstavit nedokazete. Spousta veci zije mimo vanilla, vcetne o dost komplexnejsich veci typu zfs...

O tom, co jsem ja stavel vite prd :-) V casech 2.6 kernelu jsem byl zvykly mit tuny patchu, aby mi rozumne fungovaly veci. Nepovazuju se za nejakeho velkeho contributora, ale par patchu jsem i do upstream kernelu poslal... vc. "blbosti" typu, aby fungovala zvukovka i v docku. Pokud teda pouziju nekde Ubuntu, tak je silne debloatizovane... takze tyhle sve kecy si laskave nechte od cesty :-) Muj prvni linux byl jen tak mimochodem slack-based monkey, nad umsdos fs... a je to asi uz 30 let... a bezela mi na tom i emulace 3.x Novellu, ktera rozhodne beznou soucasti nebyla... :D Muzete badat, co vse bylo potreba udelat pro to, aby to bezelo...

To není "jak u blbejch". V tomto případě to je u blbejch. S ním se fakt nebavte. On má nějaký komplex kdoví z čeho. Případ pro psychoterapeuta, ne pro vás. Jakobyste ho neznal.