No, it's a convenient thing to do and I disagree with the blocking of that patch, but that doesn't make it impossible to make things work anyway
Conversation
But the patch that made it inn needs the shim for the setup. This is far from convenient and locks you into a position where the shim is gatekeeping certain kernel features. I don't see how that is an improvement?
1
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.
1
1
1
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.
Linus understands more of the kernel than anyone should reasonably be expected to understand, and this is very different to him understanding (a) the entire kernel and (b) the OS
1
1
This, unsurprisingly, does not enable meaningful leadership underneath (arguably Lennart tried to an extent, and that did not go well)
1
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
Show replies