The Linux Kernel Prepares To Be Further Locked Down When Under UEFI Secure Boot

[quaz0r]

People in caves on the other side of the planet are plotting to demolish skyscrapers with jet fuel, you know.

you must be a conspiracy theorist! us sane people on the other hand understand that 3 skyscrapers demolishing themselves to dust at or near the acceleration of gravity due to gravitational collapse does not violate basic laws of physics at all.

[Sonadow]

Red Hat has lost its mind.

Secure Boot is supposed to protect the boot process under UEFI. How the heck does changing some GPU options on grub affect the integrity of the boot process?

This is, like they say in that Chinese idiom: drawing a snake and adding legs to it.

It's already bad enough that the kernel has mechanisms that disable loading of unsigned modules from within the OS. I had to disable those options in my own kernel just so that I can build and load those hacked 802.11ac USB drivers for Realtek and MediaTek chipsets, or they would be expensive paperweights.

And now Red Hat wants to let Secure Boot enforce these settings over userland? If these make it mainline I'm going to have another config to disable in my kernel builds.

For the record, my self-built kernel boots in Secure Boot mode. I made my notebook's UEFI recognize it as a trusted image, and thus this change will eventually affect me somehow or other.

[Veerappan]

Red Hat has lost its mind.

Secure Boot is supposed to protect the boot process under UEFI. How the heck does changing some GPU options on grub affect the integrity of the boot process?

This is, like they say in that Chinese idiom: drawing a snake and adding legs to it.

It's already bad enough that the kernel has mechanisms that disable loading of unsigned modules from within the OS. I had to disable those options in my own kernel just so that I can build and load those hacked 802.11ac USB drivers for Realtek and MediaTek chipsets, or they would be expensive paperweights.

And now Red Hat wants to let Secure Boot enforce these settings over userland? If these make it mainline I'm going to have another config to disable in my kernel builds.

For the record, my self-built kernel boots in Secure Boot mode. I made my notebook's UEFI recognize it as a trusted image, and thus this change will eventually affect me somehow or other.

The one that bit me was that VirtualBox also doesn't work with signed module enforcement, and we use that heavily at work in our development workflows via Vagrant.

I was able to get around that by converting all of my VirtualBox images to libvirt, but most of the others on my team would have given up and either gone back to Windows, gotten a Mac, or disabled Secure boot.

And I can't disable SecureBoot on my machine without losing the contents of the BitLocker enabled (IT requirement) windows partition that I keep around.

[ElectricPrism]

You can never be too safe and secure! Too free, yes, but not too safe and secure.

I'd rather not sacrifice freedom for supposed "safety" and "security", the world has and never will see true safety or true security.

A good example of this is the freedom on the internet. Trading the freedom for percieved safety is a fools move.

[chithanh]

Does this mean we can't change GPU driver module parameters as well? What if you're trying to develop a kernel module? Would you then need to disable Secure Boot to develop kernel modules?

And I can't disable SecureBoot on my machine without losing the contents of the BitLocker enabled (IT requirement) windows partition that I keep around.

No, you would just need to build your own kernel with CONFIG_LOCK_DOWN_KERNEL disabled and sign that with your own key, then add that key to the UEFI secure boot keys.

Besides there is a proposed CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ which disables kernel lockdown through SysRq combination, but whether distros are going to enable that is anyone's guess.

[bitman]

Red Hat has lost its mind.
<...>
It's already bad enough that the kernel has mechanisms that disable loading of unsigned modules from within the OS. I had to disable those options in my own kernel just so that I can build and load those hacked 802.11ac USB drivers for Realtek and MediaTek chipsets, or they would be expensive paperweights.

You have lost your mind. Kernel module signature enforcement is a great thing allowing user to remain in control of their own hardware. It is sickening to read such cowboys like you who want IT space to be wild west forever. The most important thing is that YOU CAN DISABLE IT. If it gets in your way - do not use it. Other people find it useful and use it. This is true freedom and not dystopian version of computing you would like to have.

[Sonadow]

You have lost your mind. Kernel module signature enforcement is a great thing allowing user to remain in control of their own hardware. It is sickening to read such cowboys like you who want IT space to be wild west forever. The most important thing is that YOU CAN DISABLE IT. If it gets in your way - do not use it. Other people find it useful and use it. This is true freedom and not dystopian version of computing you would like to have.

Whatever belongs to the OS should stays with the OS. Enable signed kernel module enforcement all you want as long, I don't care.

And for the record, I don't have anything against Secure Boot (i won't be using it otherwise). I take issue with letting Secure Boot control the OS post-boot. There is no reason for the platform firmware to have such hooks into a booted operating system's kernel. Right now, if this patchset is implemented, Secure Boot will:
1) Block Linux from booting if you add additional options like i915.semaphores=1 i8042.nomux=1 to the boot options in grub. Suddenly a harmless boot option has the power to compromise the entire boot process and must be blocked? And Grub does not recognize SysReq, so users who need to add additional kernel module options for a distribution to load correctly are screwed over.
2) Block unsigned modules from loading in an already running Linux installation. Great job: binary drivers and hacked drivers which are critical for like, 100% of all Nvidia GPUs and 802.11ac USB dongles are now not allowed to run on desktop Linux out of the box without recompiling the kernel or using SysReq-X.

This kind of protection rightfully belongs to dedicated appliances running Linux such as network switches or routers. Or set-top boxes. Or even smartphones and IoT appliances or Internet kiosks. But not on the commodity x64 desktop Linux installation.

[starshipeleven]

Secure Boot is supposed to protect the boot process under UEFI. How the heck does changing some GPU options on grub affect the integrity of the boot process?

Secure Boot is just one step of the chain of trust required by this patch, this patch is called "Kernel Lockdown", not "UEFI Secure Boot Locks down Linux because lulz".
The enforcement here is done by the kernel itself, not by UEFI, that has no control over what you can pass to the kernel to configure loaded modules.

If you choose to have a payload kernel that is configured to be locked down and extent the chain of trust further, then it's your own choice (or your distro maintainer's).

[duby229]

Trolling in a forum can't melt steel beams.

Maybe not.... But you know, it makes me wonder how you think neolithic man learned how to smelt iron and steel? What materials and structures do you think they used? The fact is temperatures did get high enough because it wasn't just jet fuel burning. The building was acting like a smelting furnace by pulling oxygen in a strong draft. That's how it happened. I know you were just being sarcastic and trolling, but it is what it is.

[cybertraveler]

The fact is temperatures did get high enough because it wasn't just jet fuel burning. The building was acting like a smelting furnace by pulling oxygen in a strong draft. That's how it happened.

Building 7 too? Or... you have a different, vaguely plausible story for that particular, free-falling, sky scraper.