Vlastní kernel a šifrování disku / hibernace / ..

16.3.2014 22:16 | Přečteno: 1480× | Linux, objevy | | poslední úprava: 17.3.2014 00:54

Pokud si také udržujete svoji verzi kernelu v gitu, máte pravděpodobně config vylazen přímo pro váš HW a tím pádem se můžete chlubit, že nepotřebujete ten odporný initrd/initramfs. Tedy, až do chvíle, kdy vás začnou nahlodávat vlastnosti jako šifrování rootfs, LVM pro rootfs nebo třeba hibernace. Jak na to, bez bloatware v initramfs?

Bez initramfs?

Když mě osobně začínaly zmíněné vlastnosti nahlodávat (asi dva roky zpět), hledal jsem způsob, jak zachovat svůj čistý systém LILO + vlastní lilo.conf + ručně kopírované bzImage. Něco, co mě kdysi naučila Cesta do hlubin kompilace jádra. Mou první volbou tak bylo "nějak opatchuju kernel, abych mohl specifikovat device mapper tabulku přímo kernelu" (tehdy mi voněl hlavně rootfs na LVM).

Našel jsem kupodivu víceméně hotový patch, který se sice do upstreamu podle všeho nedostal, ale který by šel nějak upravit pro současné kernely. Jenomže pak jsem začal chtít i cryptsetup a ohackovávat startup sekvenci před spuštěním initu, abych mohl zadat heslo, se mi opravdu nechtělo.

Když initramfs, tak bleskusvižný!

Tedy v C. Začal jsem zkoumat možnosti, jak mít v initramfs cpio archivu jen jednu staticky linkovanou binárku jako /init. První problémy nastaly se switch_root (tj. zjednoduššený pivot_root), kdy skutečné přepnutí do nového rootfs a smazání stop v původním tmpfs není vůbec jednoduché. Pak jsem narazil u LVM, které - ačkoli má nějaké knihovny pro userspace - prakticky nemá minimalistický C binding a pokud chci pracovat s LVM z malého C programu, ..., musím pracovat s LVM metadaty na disku ručně (a podle toho volat kernelovský device-mapper), nebo překopírovat kusy kódu z lvm binárky. Ne zrovna nejlepší / nejčistější řešení.

Když to nejde efektivně, tak vol nejmenší odpor

V tuto chvíli (~ rok průběžného průzkumu) jsem to už vzdával. Uvažoval jsem, zda by debianí initramfs-tools šly použít nějak jednodušše s vlastními kernely, aniž bych musel u každého záznamu v lilo.conf specifikovat per-kernel initramfs. Protože když něco bisectuji, tak tam mám třeba 6-7 různých verzí kernelu. Co je vlastně v initramfs tak kernel-specific? Jaderné moduly. Tedy pokud by se mi podařilo ohnout initramfs-tools tak, aby generovaly jen skripty, mohl bych nacpat device-mapper do kernelu a v lilo.conf v globálním append= uvést onen generický initramfs.

Vypadalo to slibně, /etc/initramfs-tools/initramfs.conf zmiňoval:

# MODULES: [ most | netboot | dep | list ]
# most - Add most filesystem and all harddrive drivers.
# dep - Try and guess which modules to load.
# netboot - Add the base modules, network modules, but skip block devices.
# list - Only include modules from the 'additional modules' list

Jenomže ta poslední volba nefunguje úplně dokonale. Víte, jak vám bobtná distribuční initramfs, pokud náhodou nainstalujete věci jako lvm, mdadm, cryptsetup, nfs, a já nevím co ještě? To se logika generace initramfs snaží být hloupá a místo detekce, co je pro rootfs potřeba, tam nacpe všechno, co najde. Bohužel tato logika asi nerespektuje MODULES=, takže se mi v initramfs objevovaly minimálně MD (raid) moduly. A ohackovávat distribuční logiku v /usr? Udělat si post-processing skript pro generovaný initramfs? Meh, to už není cesta nejmenšího odporu / nejmenší snahy (least-effort). Navíc - kernel v gitu mi upgrade distribuce nepřepíše. Věci v /usr/share (nebo /var/lib nebo kde systém ráčí) už ano.

Kompromis

Kdysi jsem se hrabal v busyboxu (a submitoval odvážné změny do upstreamu ), který jsem používal spolu s externími nástroji, zkompilovanými přes uClibc toolchain. Související buildroot od té doby výrazně pokročil, nabral spoustu možných balíčků (vč. X) a koncem 2013 měl přibýt i cryptsetup (byl tehdy v prvním -rc). Ten také přibyl a já tak měl své finální řešení - buildrootem sestavený userspace. Tedy busybox s defaultním configem (všechno má své hranice a já jsem líný), minimální uClibc, lvm, cryptsetup a (pro budoucí případy) mdadm. Pro probuzení z hibernace není snad nic kromě echo potřeba, jde jen o zapsání správného zařízení do /sys/power/resume, pokud se nepletu.

To vše pohodlně z prostředí domova. Stačí jen jeden make config, 20 minut nastavování a make. Jako u kernelu. Pak už následuje jen čištění nepotřebných souborů, binárek a knihoven (pokud jste použili výchozí rootfs šablonu), což zcvrkne nešifrovaných 4.9M na asi 3.5M, psaní vlastního /init (nebo /linuxrc) skriptu a je hotovo.

Balíme přes cd myinitramfs/; find . | cpio -o -H newc | gzip -9 > ../myinitramfs.gz a podáváme horké.

Na co si dát pozor

Předně - závislosti, které musí být zakompilovány do kernelu (neměl jsem ani jednu):

• CONFIG_BLK_DEV_INITRD (zřejmě)
• CONFIG_DEVTMPFS (už nemusíte jak šašci čekat na mdev)
• CONFIG_BLK_DEV_DM (pro crypt/lvm)
• CONFIG_DM_CRYPT (nezapomenout - pro crypt)

Dále také užitečné tipy pro psaní /init skriptu:

• pozor na busybox verze známých příkazů, já musel použít blkid z util-linux balíku, protože ten od busyboxu neuměl ani -U ani -L a nebyl schopen detekovat UUID u LUKS/LVM oddílů
• switch_root musí být spušťen jako PID 1, takže nezapomeňte na exec
• nikdy nedělejte resume= po mountu (ani read-only), vizte BIG FAT WARNING v Documentation/power/swsusp.txt
• u dm-cryptu mějte jméno odšifrovaného blokového zařízeni stejné, jako to v crypttabu v nainstalovaném systému, jinak budete nejspíše heslo zadávat dvakrát - další možností je prostě smazat crypttab
• redukujte si loglevel v /proc/sys/kernel/printk pro zobrazení jakéhokoli dotazu na uživatele (heslo), jinak jej (se) utopíte v debug výstupu kernelu (tedy, bez quiet)

Budoucnost, upgradeabilita (eh)

Časem se může stát, že bude potřeba aktualizovat použité binárky/knihovny v samotném initramfs. Ať už to z bezpečnostního (někdo do vanilla kernelu dostane rootkit, který exploitne cryptsetup v initramfs) nebo jiného (kernel změní ABI, i přestože to není pravděpodobné) důvodu. Výhodou initramfs-tools řešení by byla právě snadná aktualizace initramfs - stačilo by aktualizovat systém a zavolat update-initramfs. S ručně sestaveným initramfs je však potřeba stáhnout novou verzi buildrootu, znova jej nastavit (rok starý config vám nepomůže, kconfig struktura se poměrně zásadně průběžně mění), zkompilovat a nové binárky a knihovny překopírovat. Ale víte vy co? Až tak mi to nevadí. Tento zápisek není jen pro vás.

Dalším budoucím problémem může být systemd - je docela možné, že přibyde nějaká povinnost mít v initramfs i systemd, který něco nějak nastaví. Zatím tomu tak (pokud vím) není, ale je dobré to mít na paměti. uClibc buildroot podporu pro systemd má (potřebujete k němu samozřejmě minimálně udev, dbus a další kernelovské závislosti), takže pokud se vám tento "init systém" zamlouvá, můžete vesele experimentovat.

Závěrem

Pokud jste čekali hotový /init, asi vás zklamu. Já jej sice pojal modulárně,

# syntax:
#   root=<devspec>
#   rootreq=<action>
#   resume=<device>  # <device> passed to /sys/power/resume
#
#   <action>:  luks:<devspec>:cryptoname
#              lvm:vgname[/lvname]
#
#   <devspec>: /dev/sda1 , /dev/mapper/xyz, /dev/vg0/lv0, ...,
#              UUID=aa-bb-cc, major:minor
#
# (note: the order of rootreq= on cmdline matters !)
#
# example kernel cmdlines:
#   # root on LVM:
#   root=/dev/myvg/rootlv rootreq=lvm:myvg/rootlv
#   # root on encrypted partition and with volatile disk order:
#   root=/dev/mapper/root rootreq=luks:UUID=aa-bb-cc:root
#   # root on LVM LV on encrypted partition:
#   root=/dev/myvg/rootlv rootreq=luks:/dev/sda2:root_dec rootreq=lvm:myvg
#   # ... with support for hibernation:
#   root=/dev/myvg/rootlv rootreq=luks:/dev/sda2:root_dec \
#     rootreq=lvm:myvg/swaplv resume=/dev/myvg/swaplv rootreq=lvm:myvg/rootlv

ale v zásadě stačí jen trojice mountů (devtmpfs, proc, sysfs) na začátku, s následnými cryptsetup/lvm příkazy, mountem rootfs, uklizením (umount /dev, /proc, /sys) a switch_rootem. U mě to celkem se všemi (dlouhými) komentáři, README, ..., dává 2.6MB kernel + 1.8MB initramfs, oboje v gzipu.

Snad vám tento zápisek dal něco víc, než všechny ostatní návody na tvorbu initramfs. Praktickým cvičením / domácím úkolem budiž tvorba vlastního /init skriptu.

       

Komentáře

[Ondrej 'SanTiago' Zajicek]

Odkud se vlastne v pripade rootu na LVM ten kernel a initramfs natahuje? Je tam tradicni partition table a separatni /boot partition pro kernel a zavadec? Pokud ano, nebylo by cistsi se vykaslat na initramfs, nabootovat s boot partition jako rootem, z ni aktivovat LVM a pak provest pivot_root na skutecnou root partition (a remountovat boot partition do /boot)? Nebo je /boot samostatny logical volume v ramci LVM? Pak by byl asi samostatny initramfs nevyhnutelny.

[Jiří J.]

V mém případě je to typicky /boot na partišně zvlášť, ale mělo by to stejným způsobem fungovat i s LVM LV, pokud se dané LV nepohne. Jasně, mít druhý root pro aktivaci LVM/crypto/... by samozřejmě šlo, ale:

• mohly by nastat problémy při probuzení z hibernace
• moc bych si nepomohl - obsah by byl víceméně stejný, jen by nebyl zabalen do cpio+gz ... a nemusel bych mít v kernelu podporu pro initrd/initramfs, za cenu bordelu v /boot (nebo nutnosti vytvářet partišnu zvlášť)

[Miriam]

Máš moc pěknej blog, fešáčku. Měli by ti okamžitě lupnout tučnáčka. Vlastně se divím, že ti ho ještě nedali.

[petr_p]

To funguje jen do té doby, než jádro nainicializuje bloková zařízení v jiném pořadí. Proto se autor páral s blockid.

Kdyby parametr root přijímal topologické cesty (něco jako cesta v sysfs), tak by ani blockid nebylo (kromě lokálního SCSI a rootu na síti) třeba. V systémech s IDE jsou cesty statické, protože řadič má pevnou topologii (primární/sekundární kanál, master/slave zařízení). Zrovna tak SATA má jednotlivé linky staticky číslované. USB to samé.

[Kvakor]

Je pravda, že initram<něco> je třeba, pokud je rootfs šifrovaný a/nebo na LVM/RAIDu/síti/jánevímkdeještě, ale pro hibernaci to neplatí, u té stačí jen natvrdo zakompilovat do jádra partition, na které se ukládá image (volba *configu Power management and ACPI options/Default resume partition, aneb option CONFIG_PM_STD_PARTITION) plus příslušné ovladače k disku, na kterém se nachází. Pokud je v PC jeden disk s jedním swapem, stačí nastavit příslušnou partition. Pokud ne, bude to fungovat jen tehdy, když jádro při startu nadetekuje disky pokaždé ve stejném pořadí.

[Jiří J.]

Ano, je pravda, že pro probuzení z hibernace není vůbec initramfs potřeba, pokud je vše na oddílech, které umí rozpoznat kernel. Z Documentation/power/swsusp.txt:

. The resume process checks for the presence of the resume device,
if found, it then checks the contents for the hibernation image signature.
If both are found, it resumes the hibernation image.

. The resume process may be triggered in two ways:
  1) During lateinit:  If resume=/dev/your_swap_partition is specified on
     the kernel command line, lateinit runs the resume process.  If the
     resume device has not been probed yet, the resume process fails and
     bootup continues.
  2) Manually from an initrd or initramfs:  May be run from
     the init script by using the /sys/power/resume file.  It is vital
     that this be done prior to remounting any filesystems (even as
     read-only) otherwise data may be corrupted.

Jenomže já už dříve měl šifrovaný home, který jsem odšifrovával až po přihlášení pomocí speciálního skriptu, který jsem měl místo shellu v /etc/passwd, takže nešifrovaný swap se všemi klíči na disku tak nějak nepřipadal v úvahu.

Každopádně díky za poznámku, možná se bude hodit ostatním.

[Max]

Osobně proti initrd nic nemám, beru jej jako čisté systémové řešení. Jestli je boot o 1s pomalejší mně netrápí, pc uspávám. Je pravda, že se to někde může hodit. Stejně tak jsem už před několika lety přestal řešit vlastní kernel, jednoduše vše funguje a tak netřeba řešit, ba naopak, člověk by musel vždy něco dokompilovávat (virtualbox moduly, grafiku apod.). Podle mně je doba, kdy si uživatel kompiluje vlastní kernel tatam. Každopádně pěkné počtení, mé díky autorovi.
Zdar Max

[Bedňa]

Podle mně je doba, kdy si uživatel kompiluje vlastní kernel tatam.

Už pred rokmi vyselo na kernel.org, "nebojte sa skompilovať si svoje jadro, je to sranda" a môžem to potvrdiť, predsa o tú nám ide v prvom rade

Kompilácia má dnes význam na embedded systémoch, kde sa po zapnutí vyžaduje okamžitý štart, na desktope to už fakt nemá veľké opodstatnenie, ale že zábava to fakt je.

[-ff-]

"nebojte sa skompilovať si svoje jadro, je to sranda"

Není to sranda. Některé netbooky se při kompilaci kernelu těžce přehřívají a mají tendenci se vypínat v průběhu práce. Kompilace kernelu je pro takové stroje dlouhá a silně zatěžující záležitost.

[Bedňa]

Kompilácia sa dá spustiť na pozadiť s nízkou prioritou. O srandu ide hlavne v tom ako sa to dá pekne osekať až do stavu kedy to nebootne

[Josef Kufner]

Některé netbooky se při kompilaci kernelu těžce přehřívají a mají tendenci se vypínat v průběhu práce.

Není to na reklamaci?

[pavlix]

Kdybys měl reklamovat všechno, co vykazuje znaky šmejdu, tak můžeš reklamování zasvětit celý svůj život ;).

[Kvakor]

Některé netbooky se při kompilaci kernelu těžce přehřívají a mají tendenci se vypínat v průběhu práce.

Já to řeším podtaktováním, sice se úměrně prodlouží doba kompilace, ale vyhne se tím přehřátí. Pokud nejde podtaktovat, je tu ještě možnost čas od času kopmpilaci pozastavit (např. ScrollLockem na konzoli, posíláním SIGSTOP/SIGCOND a pod.), dokud se zase stroj nevychladí.

[Jiří J.]

Čistě mimochodem - na noteboocích s i3/i5/i7 procesory hodně pomáhá vypnutí turbo boost (Thinkpad X220, z 97C na 86C), na kernelu 3.9+ (kde je nový pstate driver) stačí prostě:

echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

[pavlix]

Když ten pstate driver nemám, tak se to chová jako zapnuté nebo vypnuté?

[Jiří J.]

Zapnuté, samozřejmě, je to featura na zrychlení jednovláknových aplikací. Dá se to vypnout i jinak, pokud to nejde v BIOSu (na desktopech jde, na serverech často taky, na laptopech málokdy). Docela mě to dostávalo, když jsem undervoltovával C2D (tehdy se tomu říkalo IDA). Možná by se taky mohla hodit utilitka turbostat, která je někde v tools/ ve zdrojácích kernelu.

[Jiří J.]

Jelikož se tak trochu pohybuji na hranici "HiFi", tak narážím často na USB zařízení, která mají problémy s drivery. Ať už to kvůli nekompetenci zařízení (nutnost přidat quirk do alsy) nebo kvůli hroznému stavu TT schedulingu u EHCI driveru, který Alan Stern připomíná u každého revertu / regresního fixu:

    This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
    (USB: EHCI: fix bug in scheduling periodic split transfers).  The
    commit was valid -- it fixed a real bug -- but the periodic scheduler
    in ehci-hcd is in such bad shape (especially the part that handles
    split transactions) that fixing one bug is very likely to cause
    another to surface.  That's what happened in this case; the result was
    choppy and noisy playback on certain 24-bit audio devices.

    The only real fix will be to rewrite this entire section of code.  My
    next project...

Možná se jednou dočkáme přepisu EHCI driveru, možná to brzo bude jedno (XHCI) / zařízení používající USB2.0 High Speed, možná začnou výrobci HW následovat standardy, možná dostanu hodinky s vodotryskem. Alespoň to poslední začíná pomalu vypadat reálně.

Kromě toho mám pár commitů, které udržuji čistě kvůli pohodlí - jako ochrana proti zamknutí cdrom mechaniky, změna "Disabling IRQ" na KERN_WARNING, aby mi nvidia driver nespamoval konzole, apod.

Obecně ale i u mě platí to, že tam, kde stačí distribuční kernel, nekompiluji vlastní.

[Jendа]

Podle mně je doba, kdy si uživatel kompiluje vlastní kernel tatam.

Já teda taky používám distribuční, ale dokážu si představit, že budu potřebovat vlastní. Třeba kdybych ladil drivery, používal nějaké security patche jako grsec nebo chtěl mrkva.ko, kterej se asi do upstreamu jen tak nedostane :).