But it's not "just inject the key". It moves the responsibility around completely for the linux distro. It's hard enough to comply with Microsoft shim requiements and now you are adding another singular key, along with having to resign N number of dkms packages pr kernel.
Conversation
If you're complying with the Microsoft requirements then you have to use Shim, because Microsoft won't sign GPLed code. You can't separate those two things.
2
2
If you want to make DKMS work out of the box with secure boot, then yeah, that's not happening, and that's a deliberate design choice because there's no way to make that work without compromising the model
2
I don't need "out of the box" support, but something that wouldn't be gatekept by shim would be nice. I shouldn't be forced into the shim+grub setup because I want to have secure boot enabled.
1
I agree that a model where a key is trusted to boot the kernel but not trusted to load modules in that kernel is broken
1
4
I find it strange that nobody reflected on this while accepting the MOK patches. But after trying to fix a TPM bug it seems to me anything is accepted if it has the right name attached to it :/
1
2
Linux has no meaningful structure for providing security leadership and I think that results in a lack of coherent design choices
1
5
I think the lack of overall privacy and security design / implementation work for the whole platform is the main issue. The Linux kernel not having an official userspace also means they run tons of stuff in kernel space for no particular reason, just because they want to ship it.
2
4
Ideally the kernel could spawn isolated processes protected from the rest of userspace but not privileged themselves, and then not only could they move a ton of functionality to those and largely / entirely get rid of userspace helpers, but could ship a more coherent OS overall.
1
1
Yeah let's have a separate mount namespace that's only accessible inside the kernel and punt things like asn.1 parsing out into that
2
1
A ton of driver stuff could also be in isolated processes with no performance hit. There's a major performance incentive to have TCP/IP and filesystems in the kernel, but it would be pretty cool if there was a way to optionally use the kernel filesystems as isolated processes.
i.e. some kind of stub filesystem drivers that proxies to kernel filesystems in an isolated process and essentially provides what FUSE does but with the official kernel filesystem drivers. I wish Linux had a whole lot more work on that stuff, not just piles of weak mitigations.
1
1
Or as another example, the kernel GPU drivers are not really doing anything that could not be done in isolated processes with no performance impact. It's pretty sad Windows has those drivers isolated but Linux doesn't and Linux is falling further behind macOS/Windows on that.
1
1
1
Show replies