Vlákno názorů k článku FFmpeg 5.0 je venku, Ubuntu 22.04 LTS zůstane u jádra Linux 5.15 od k3dAR - ad "uživatelé velmi nového hardwaru budou nejspíš sahat...

ad "uživatelé velmi nového hardwaru budou nejspíš sahat po repozitářích typu Ubuntu Mainline Kernel PPA."

no ono nejde jen o uzivatele "velmi noveho HW", ale i o uzivatele co chteji Hibernovat se zapnutym SecureBoot, protoze pred casem (lety?) nekdo fakt hloupe rozhodl, ze hibernovat se SecureBoot neni bezpecne a v systemovych/re­positarovych jadrech je to umele zablokovane...
pritom rozdil mezi startem cistym a z hibernace neni z pohledu bezpecnosti ZADNEJ rozdil, nacte se bezpecne jadro a initramfs a jeho scripty bud prepnou na rootfs, nebo ho obnovej ze swap, v pripade nepouziti sifrovani budiz, obsah swapu je mozne citelnej, ale ta blokovana hibernace je i kdyz je pouzit LUKS na rootfs a s nim uz je to opravdu hovadina...
takze abych mohl hibernovat, mam UbuntuMainline jadro, i presto ze nepouzivam btrfs, bezi to na 10let starem NB, atd...

a pak je tu druha vec, "pripravatorum" "Ubuntu Mainline Kernel PPA" asi spadne neco na hlavu... dlouhodobe platilo "nepsane(?)" pravidlo ze ty jadra behali ve vsech dostupnych vydani *buntu, pred par mesici ale navysili zavyslot na libc6, takze preslo chodit v *buntu 18.04, pak opet zvedli pozadovanou verzi libc6 ze prestalo chodit bv *buntu 20.04 (tedy poslednim LTS vydani), nedavno aby toho nebylo malo, zmenili zavyslost (od 5.15.7) z libssl1 na libssl3 coz je balicek kterej je dostupnej POUZE v NEvydanym *buntu 22.04, takze dnes oficialne ZADNE vydane *buntu NEumoznuje instalaci UbuntuMainline­Kernel....

protoze jak sem psal potrebuju ho k hibernaci se SecureBoot pripravil sem si nejdriv pro svoje potreby, pak to hodil na github jednoduchej nastroj na instalaci jadra z UbuntuMainline­Kernel kde zminene veci resim "workaroundama" (i kdyz nektere pravda spinave, no zatim funkcni :)
a aktualne mam 5.16.0 v Xubuntu 20.04...

https://github.com/k3dar/kumk

"pripravatorum" "Ubuntu Mainline Kernel PPA" asi spadne neco na hlavu...

podla situacie Mainline uz davno spadlo, co k tomu dodat... asi len toto:
Banda tupych hlav (linka obsahuje hudobne video k teme)

jasne to byl preklep, samozrejme sem myslel "asi spadlo neco na hlavu" :)

> nekdo fakt hloupe rozhodl, ze hibernovat se SecureBoot neni bezpecne a v systemovych/re­positarovych jadrech je to umele zablokovane...
pritom rozdil mezi startem cistym a z hibernace neni z pohledu bezpecnosti ZADNEJ rozdil,

Znie to tak jednoducho a pritom je to zle...

The obvious question is "what does hibernation have to do with keeping root out of kernel space", and the answer is a little convoluted and is tied into how Linux implements hibernation. Basically, Linux saves system state into the swap partition and modifies the header to indicate that there's a hibernation image there instead of swap. On the next boot, the kernel sees the header indicating that it's a hibernation image, copies the contents of the swap partition back into RAM, and then jumps back into the old kernel code. What ensures that the hibernation image was actually written out by the kernel? Absolutely nothing, which means a motivated attacker with root access could turn off swap, write a hibernation image to the swap partition themselves, and then reboot. The kernel would happily resume into the attacker's image, giving the attacker control over what gets copied back into kernel space.

(Zdroj: https://mjg59.dreamwidth.org/55845.html)

> attacker with root access

tak utocnik s root pristupem je asi irelevantni ze muze podvrhnout hibernacni image do swapu, kdyz muze snadneji pozmenit systemove soubory primo v rootfs, nahrat keyloger, rootkit... ;-)

nicmene chapes, ze tebou popisovanej "problem" je totozne i kdyz HW nema (zaplej ci dostupnej) SecureBoot, pritom bez nej stock jadro v *buntu normalne hibernuje?

> tak utocnik s root pristupem je asi irelevantni ze muze podvrhnout hibernacni image do swapu, kdyz muze snadneji pozmenit systemove soubory primo v rootfs, nahrat keyloger, rootkit... ;-)

To nie je celkom tak pravda. Su veci, ktore nevie urobit ani root z userspace, a musi o ne poziadat jadro, aby ich urobil z kernel space. No a ked jadro na to nema kod, treba ho nahrat. Pri zapnutom Secure Boot musia byt aj moduly podpisane a podpis sa kontroluje pri natiahnuti. Pokial si vsak root nieco matla do swapoveho image, ktory sa neskor natiahne bez akejkolvek kontroly, tak sa takato kontrola obide.

> nicmene chapes, ze tebou popisovanej "problem" je totozne i kdyz HW nema (zaplej ci dostupnej) SecureBoot, pritom bez nej stock jadro v *buntu normalne hibernuje?

Ano. Ale chapes, ze Secure Boot zapinas presne na to, aby taketo obchadzanie nebolo mozne? Ked to nechces, Secure Boot si vypni.

@bez přezdívky

nenapada me situace kdy moznost utocnika co ma root, zdiskreditoat hibernate image ve swap by byla horsi nez ze ten utocnik rovnou si vytahne data, prida zadni remote vratka, nahodi keyloger, atd... tedy nic k cemu bu potreboval pridat kernel modul bez podpisu...

proc?? bych si mel vypnout SecureBoot? sem na zacatku jasne (asi jak pro koho ;-) psal ze pouzivam SecureBoot a zaroven hibernaci a proto nemam moznost pouzit distro-stock jadro, ale musim pouzit UbuntuKernelMa­inline (nebo si muzu zbuildit vlastni) kde toto umele omezeni znemozneni hibernace se zaplym SecureBoot neni...