Skip Navigation
Linux @lemmy.ml
𞋮𝛂𝛋𝛆 @lemmy.world

Secure Boot, signed kernel modules (for shitvidia), and the Shim - Why does the kernel need to support SB after the handover? Can a graphics coprocessor just run as a hotpluged module unsigned?

Asking about why the kernel needs to support secure boot on an individual system where I am not concerned about the hole punched by the nvidia kernel module. I'm concerned about the proprietary boot loader firmware that will never be maintained well. I'm not asking if it is a good idea in general or for most people.

Shit Gigabyte Aorus YE5 laptop doesn't support custom secure boot keys for PK in the bootloader. AVOID these thieves selling hardware you can't own.

Why can't an unsigned shitvidia kernel module run as a hotplugged device from user space without causing a problem with secure boot handover?

I can run Fedora with secure boot using the Microsoft 3rd party key. I just can't enable the shitvidia GPU. My primary use case is for LLM/stable diffusion, the GPU doesn't matter for graphics.

5 comments

  • The reason is simple: in order to be a signed piece of secure boot software, the kernel needs to do everything possible to prevent unsigned code from running at the kernel's privilege level, or risk its signing key getting revoked by Microsoft.

    I assume your kernel is from Fedora and is signed. If your kernel, once loaded, allowed the loading of unsigned kernel modules, then any attacker could use it as part of an exploit that allows them to break secure boot. They would simply include a copy of the Fedora kernel, and then write a custom kernel module which takes control of the machine and continues their attack. The resulting exploit could be used on any system to bypass and defeat secure boot. In essence, secure boot is only as secure as the weakest signed implementation out there.

    So, Linux distributors need to demonstrate to Microsoft that they don't allow unsigned kernel code execution. Linux contains a feature called lockdown, which implements this idea. In order to be effective, lockdown must be automatically enabled by the kernel if secure boot is enabled. Interestingly, Linus flat out refuses to include the code to do that, I guess he disagrees with it. So a little discussed reality of secure boot is that, all Linux kernels which are signed have this extra patch included in order to enable lockdown during secure boot.

    And that is why you can't load an unsigned module when secure boot is enabled.

  • This is most likely there to patch holes from Windows than having anything to do with Linux specifically, as Linux is always an afterthought anyway for these manufacturers.

    I think the idea is that hybrid GPUs on laptops are a lot more intimate with the CPU because of memory sharing and needing to DMA between the two GPUs directly. So you can't exploit the GPU to rootkit the OS. Although I'm sure there's a lot of ways to bypass that anyway from within Windows...

    • In my case here, I have a 16GBV 3080Ti paired with a 12 gen i7. The integrated graphics for the i7 are fine for all graphics operations I need. I got the GPU specifically for LLM stuff. The system memory is DDR5 and the GPU is DDR6. It is an optimus design, so it is a bit different than a desktop, but from what I've read, this is just a matter of thermal and power throttling features that are broken out for kernel controls that are not present in the desktop cards.

      The bootloader issues are universal to all platforms that use UEFI. There are several documents available from the UEFI Consortium and NIST that cover the subject in detail and how to mitigate the problems.

  • I'm not sure I properly understand your problem, but perhabs your kernel is compiled with CONFIG_MODULE_SIG_FORCE. You can check with grep CONFIG_MODULE_SIG_FORCE /boot/config-$(uname -r). If it isn't you could try and run the kernel with module.sig_enforce=0 as a parameter and see if that helps.

    If you don't need secure boot, then just disable it (if possible).