Originally posted by InsideJob
View Post
Announcement
Collapse
No announcement yet.
The Linux Kernel Prepares To Be Further Locked Down When Under UEFI Secure Boot
Collapse
X
-
- Likes 1
-
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.Last edited by Sonadow; 01 March 2018, 08:26 PM.
- Likes 3
Comment
-
Originally posted by Sonadow View PostRed 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.
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.
- Likes 1
Comment
-
Originally posted by InsideJob View PostYou can never be too safe and secure! Too free, yes, but not too safe and secure.
A good example of this is the freedom on the internet. Trading the freedom for percieved safety is a fools move.
- Likes 2
Comment
-
Originally posted by sandy8925 View PostDoes 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?Originally posted by Veerappan View PostAnd I can't disable SecureBoot on my machine without losing the contents of the BitLocker enabled (IT requirement) windows partition that I keep around.
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.
Comment
-
Originally posted by Sonadow View PostRed 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.
Comment
-
Originally posted by bitman View Post
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.
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.Last edited by Sonadow; 02 March 2018, 06:02 AM.
- Likes 2
Comment
-
Originally posted by Sonadow View PostSecure 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?
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).
Comment
-
Originally posted by starshipeleven View PostTrolling in a forum can't melt steel beams.
Comment
-
Originally posted by duby229 View PostThe 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.
Comment
Comment