Ehm ... takze bude potreba hacknou blokovac modulu, ... 3, 2, 1 ... hotovo.
"Blokovač" sám aktivně nic neblokuje, vyrobí jen konfigurační soubory, co se dál používají úplně standardně (modprobe, sysctl, parametry startu jádra). Pokud někdo obejde zabezpečení těchhle nástrojů, mechanismů a bude to moct ovládat např. jako standardní uživatel, tak máme všichni ještě řádově větší problém.
Nebylo by mnohem lepsi aby tam proste vubec nebyly?
Bylo i nebylo, už jsem to psal výše. Jestli to chcete řešit, tak je trochu rozdíl mezi tím tohle dělat např. na svém počítači a notebooku s jednou distribucí, kde máte vždycky celý toolchain a můžete si s tím blbnout do aleluja, vracet se, když se něco nepovede atp., a pak třeba na desítkách serverů a stanic s nějakými okny pro údržbu, kde máte různé kombinace distribucí, jejich verzí podle aplikací, použití (bare metal, virtuály) a potřebných modulů..
Postavíte si na každou používanou distribuci nějaký specifický build host..? Uděláte si automatizaci, abyste mohl snadno rebuildovat s vašimi konfigy upstream verze do balíčků? Budete to mít podepsané pro secure boot a všude správné MOK v UEFI?
Zvládnete registrovat, jestli se třeba v těch aktualizovaných upstream jádrech nezměnily nějaké volby nebo chování (i na LTS jádrech můžete mít nějaké backporty, když se mění minor verze distribuce), budete to testovat?
Když bude potřeba změna konfigurace (nevím, budete např. chtít rozběhnout ad-hoc wireguard tunel), tak půjdete upravovat konfig a sestavovat nové jádro?
Oproti tomu ty jednoduše verzovatelné soubory, co se dají snadno upravovat a aplikovat, jsou prakticky mnohem schůdnější.