Jak nahackovat Fedora kernel do RHEL klonů

8.4.2012 18:17 | Přečteno: 1416× | programování |

Nedávno jsem narazil na dost nepříjemný bug v kernelu způsobující kernel panic u wifi připojení v případě některých routerů. V kernelu už fix je, jenže v 3.2 větvi, přičemž RHEL klony jedou na 2.6.32 větvi s backportovanými bugfixmi. Jenže zrovna tenhle bugfix chyběl, tak nezbývalo než upgradovat na 3.x, podle možnosti s minimem vynaloženého úsilí.

Bug 731365

RedHat vede uvedený bug jako bug 731365. Z hlavičky v bugzille je vidět, že v kernelu 3.2.1-3.fc16 je opraven. Prvý impluz velí stáhnout src.rpm a zbuildit, tak jsem se do toho pustil. Kernel se zbuildil, ale někde to vyhořelo na balíčkovaní. Nechtělo se mi moc řešit kde je přesně problém, protože build na třech jádrech trval hodinu. Šlo by ovšem ořezat nepotřebné moduly z configu, ale to by mi trvalo ještě déle. Navíc bych to musel opakovat při každém upgradu.

V TODO listu mám vytvoření build serveru který by to překládal, ale zatím jsem to potřeboval nějak ohackovat. Po pár pokusech jsem narazil na funkční postup, jenž je popsán níže.

Repo soubory pro yum z Fedory

Z Fedory 16 si do /etc/yum.repos.d/ přidáme fedoří repozitáře, ale vybereme jenom kerneloidní balíčky přes includepkgs klauzuli. Další úpravy jsou nahrazení proměnných jako $releasever, klíče jsou zakomentovány (importujte manuálně přes rpm --import ze stránek fedoraproject.org) Soubory pak vypadají následovně:

[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-16&arch=$basearch
enabled=1
includepkgs=kernel kernel-debuginfo kernel-debuginfo-common-x86_64 kernel-devel kernel-firmware kernel-headers linux-firmware grubby dkms
gpgcheck=1

[fedora-debuginfo]
name=Fedora $releasever - $basearch - Debug
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-16&arch=$basearch
enabled=1
includepkgs=kernel kernel-debuginfo kernel-debuginfo-common-x86_64 kernel-devel kernel-firmware kernel-headers linux-firmware grubby dkms
metadata_expire=7d
gpgcheck=1

[fedora-source]
name=Fedora $releasever - Source
failovermethod=priority
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-source-16&arch=$basearch
enabled=0
includepkgs=kernel kernel-debuginfo kernel-debuginfo-common-x86_64 kernel-devel kernel-firmware kernel-headers linux-firmware grubby dkms
metadata_expire=7d
gpgcheck=1


# FEDORA UPDATES


[fedora-updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f16&arch=$basearch
enabled=1
includepkgs=kernel kernel-debuginfo kernel-debuginfo-common-x86_64 kernel-devel kernel-firmware kernel-headers linux-firmware grubby dkms
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

[fedora-updates-debuginfo]
name=Fedora $releasever - $basearch - Updates - Debug
failovermethod=priority
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f16&arch=$basearch
enabled=1
includepkgs=kernel kernel-debuginfo kernel-debuginfo-common-x86_64 kernel-devel kernel-firmware kernel-headers linux-firmware grubby dkms
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

[fedora-updates-source]
name=Fedora $releasever - Updates Source
failovermethod=priority
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-source-f16&arch=$basearch
enabled=0
includepkgs=kernel kernel-debuginfo kernel-debuginfo-common-x86_64 kernel-devel kernel-firmware kernel-headers linux-firmware grubby dkms
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

Ohackování glibc symbolů

Fedora má novější glibc než RHEL a proto některé balíčky nelze jednoduše nainstalovat. Problém byl myslím jen s module-init-tools, ten stačí překompilovat s mock nebo rpmbuild (trvá pár sekund). Případný update module-init-tools z yum repozitáře v budoucnu pak zařve a build se opět bude muset udělat ručně, ale module-init-tools zrovna moc často updatované nejsou. Viz HOWTO k rpmbuild-u a mock-u, pak zbývalo jen doinstalovat rpmdevtools. Zde jenom zmíním užitečný příkaz yum provides '*/bin/rpmdev-setuptree', který ušetří googlování, kterýže to balík nainstalovat (poslední argument je hledaný soubor). Zbuildění module-init-tools lze provést jedním z dvou způsobů, mock-em:

mock --rebuild module-init-tools-3.16-5.fc16.src.rpm
#balíček se pak objeví ve /var/lib/mock/$mock-config/result (default)

nebo rpmbuild-em:

rpm -Uvh module-init-tools-3.16-5.fc16.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bb module-init-tools.spec
#balíček se pak objeví ve ~/rpmbuild/RPMS

Hlavní rozdíl mezi rpmbuild a mock je, že mock si vytvoří alternativní root strom pro build ve /var/lib/mock/$mock-config (lze tudíž buildit i pro jiné distra), kdežto rpmbuild používá headery a knihovny z aktuálního systému. Default mock config se nastavuje pomocí symlinku /etc/mock/default.cfg.

Po nainstalování zbuilděných module-init-tools už jenom stačí provést yum update a rebootovat do nového kernelu.

V novém kernelu

Po pár týdnech v kernelu 3.3.x téměř všechno funguje, změny které jsem zaznamenal:

• wifi funguje, původní bug je skutečně opraven
• navíc se rozběhla čtečka SD/MMC karet (driver je už i ve starších jádrech 2.6.x, ale zrovna na mém thinkpadu s tím byl nějaký problém)
• rozbil se framebuffer pro intelí i nvidia grafiku (nVidia Optimus), ale to až tak moc nevadí, akorát jsem přišel o bootovací splash-screen (je možné že jsem zapomněl updatnout některý balíček?)
• sleduji ještě jak se chovají kworker-y, ale zatím žádný problém popisován v bugách z předchozích jader (obyčejně žravost CPU) - pokud by to někoho zajímalo, údajně postačí vypnout USB autosuspend, jak jsem pochopil z popisu bugů

VirtualBox s DKMS s novým kernelem

V novém kernelu je i pár binárek, které jsou zbuilděny proti novější glibc. Ale stačí je jen překompilovat a DKMS udělá zbytek:

export KERNELVER=3.3.1-2.fc16.x86_64
export KERNELSRC=/usr/src/kernels/$KERNELVER/
(cd $KERNELSRC/scripts/basic && gcc fixdep.c -o fixdep); (cd $KERNELSRC/scripts/mod && gcc modpost.c file2alias.c sumversion.c -o modpost)
#Následující dva příkazy jsou jen pro otestování buildu před rebootem do nového kernelu.
#Jinak to /etc/init.d/dkms_autoinstaller udělá při bootu.
dkms autoinstall --kernelver $KERNELVER
find /lib/modules/ -name "vbox*.ko"

Miscellanea (týkající se především SELinuxu)

Zmíním pár drobností, na které jsem narazil a mohli by být užitečné i pro někoho jiného. Mám relativně menší /var partition, proto jsem musel řešit přesun mysql datadir. V mysql configu se to nastaví hned, pak je potřeba vysvětlit to SELinuxu. Mysql datadir jsem přesunul do /home/mysqldb, pak stačí přidat odpovídající záznamy do nového souboru /etc/selinux/$POLICYTYPE/contexts/files/file_contexts.local (v druhém řádku jsou taby mezi sloupcema, nevím jestli na to záleží):

/home/mysqldb(/.*)?    system_u:object_r:mysqld_db_t:s0
/home/mysqldb/tmp	-d	system_u:object_r:tmp_t:s0

SELinuxu odkážeme ať spustí relabel (kontext lze měnit i přes chcon -R --reference=/var/lib/mysql /home/mysqldb/, ale kvůli relabelu to není permanentní):

restorecon -R -v /home/mysqldb

Přepínač --selinux u tar-u umožňuje uložit SELinux labely (užitečné pro zálohy).

Před několika dny jsem narazil na chybný balíček ldns z rpmforge - chyběl mu podpis a yum update kvůli tomu hlásil problémy se závislostma. Řešení je buď ručná rekompilace nebo já jsem ho prostě mrsknul do exclude direktivy v konfigu repozitáře (stejná verze je i v EPELu). Poučení do budoucna - při přidávání nových repozitářů je nejlepší postup explicitně určit via includepkgs jaké balíky se mají povolit (člověk se pak vyhne ABI konfliktům kvůli nezměněnému soname). Pro účely testování jsem si ve VirtualBoxu rozběhnul Fedoru 16 (asi si tam hodím pak i 17 alpha).

Nakonec jsem dokonvergoval k "distribuci" Scientific Gentoo: nastavit lze v zásadě všechno co v Gentoo, ale nemusí se všechno kompilovat. Balíčky jsou většinou otestované, ale není problém přidat "bleeding edge" verze (v případě složitého konfliktu verzí to prásknu buď do /opt nebo do virtuálu, ale to jsem zatím řešil jen s vlc kvůli nekompatibilnímu ABI; nejspíš by stačilo vlc překompilovat ze src.rpm).

Otevřená otázka - detekce změn ABI v ELFech

Znáte někdo nástroj, který dostane dva ELFy, headery k nim a zjistí, v čem se liší ABI? Které symboly jsou nové, kde se změnil typ parametrů nebo počet, atd. S mcpp a gcc-xml by pravděpodobně takový nástroj šlo napsat. Nemusí být dokonalý, třeba by mi nevadilo, pokud si na i686 zmýlí int a pointer (ne možná nejlepší příklad). Trocha bych se bál, zda to nenarazí na halting problem u "přema(sa)krovaných" headerů, ale za pokus by to stálo.

       

Komentáře

[kavol]

V kernelu už fix je, jenže v 3.2 větvi, přičemž RHEL klony jedou na 2.6.32 větvi s backportovanými bugfixmi.

hm, a patch z 2.6.41 by na 2.6.32 neprošel?

Jenže zrovna tenhle bugfix chyběl, tak nezbývalo než upgradovat na 3.x

fakt?

[limit_false]

fakt?

"You are not authorized to access bug #794738"

[kavol]

zajímavé, ještě jsem speciálně dával pozor, abych neodkázal privátní komentář, a von je celej bug omezenej, i když to není security ani nic podobnýho ...?

každopádně tedy pointa je, že bugfix už nějaký pátek existuje, když nemůžeš na testovací buildy, tak dočkej času jako husa klasu, než to probublá procesem

[limit_false]

Nejsem si úplně jistý jestli definitivně ten bug není security-related. Určitě je to DoS, přepisuje se kernel memory. Zda to může vést k code execution, netuším.

[kavol]

což o to, ti naši experti dokážou vykřesat bezpečnostní problém prakticky ze všeho, ale myslel jsem to tak, že to není příslušně označené (a problém je veřejně známý, ta fedoří verze bugu je přístupná)

[Michal Kubeček]

hm, a patch z 2.6.41 by na 2.6.32 neprošel?

I kdyby neprošel hladce, backportovat ho by téměř jistě znamenalo řádově méně práce než spolehlivě rozchodit jádro 3.3 na distribuci postavené na 2.6.32.

[Michal Kubeček]

Jak tak vidím ten patch, tak by nejspíš ani nebylo potřeba nic backportovat a stačilo by prostě z balíčku vyhodit patch backportující tu problematickou featuru…

[limit_false]

Který patch? Ten co je v tom privátním bugu? Nebo nějaký jiný?

[Michal Kubeček]

Měl jsem na mysli tenhle, odkaz na něj je v komentáři 82 toho veřejného bugu (k neveřejným nemám přístup). Ale moc důkladně jsem ho neprohlížel, podle komentáře to vypadá, že to není jen čistý revert. I tak bych ale řekl, že backportovat to na RHEL 2.6.32 jádro bude méně pracné než tam dostat celé jádro 3.3 - a to říkám přesto, že se sám zabývám adaptací jádra 3.0 ze SLE 11 SP2 do OpenSuSE 11.4 (nebo spíš právě proto).

Jinak po troše pátrání se dá zjistit, že ten patch je už i v Linusově stromu (commit e76aadc5, zahrnut v 3.3rc1).

[kavol]

Měl jsem na mysli tenhle, odkaz na něj je v komentáři 82 toho veřejného bugu (k neveřejným nemám přístup).

to je vpodstatě ono, v první části komentáře jsem narážel na to, že kernel-2.6.41.6-1.fc15 has been submitted as an update for Fedora 15.

[Lukáš Kotek]

Neřešil by Váš problém repozitář elrepo? Konkrétně v elrepo-kernel je momentálně jádro ve verzích 3.0.27 a 3.3.1.

[limit_false]

Aha, dík, tento repozitář jsem nevygooglil ani rpm "searchátka" ho nenašly. Tak jsem si trocha zahackoval (BTW: kernel se v elrepo jmenuje kernel-ml)

Jinak nechápu proč nikde nemají veřejně googlitelnej fingerprint nebo klíč stáhnutelnej přes https; klíč ani není nikým podepsán (naštěstí to není moc běžné, ale už jsem pár takových repo viděl).

[Lukáš Kotek]

Není zač Já na něj narazil vlastně jen náhodou - přes web CentOSu

[Václav Kramář]

Asi nevhodná volba klíčového slova. Odkaz na správnou sekci wiki CentOS mi mi strejda Google nabídl hned jako druhý . Tohle je IMHO nejjednodušší cesta k novějšímu kernelu do RHEL a klonů (u mně kvůli Wi-Fi).

[Dan Horák]

detekce změn v ELFech - co třeba abi-complaince-checker a Remiho blog jako ukázka použití?

[limit_false]

Dík, vyzkouším.