All distros “support” SB because SB is not part of Linux and it requires setting your own SB keys. That is outside of easy scope. The question is if they support the m$ signed shim and what system is used to achieve this. Fed uses Anaconda (unrelated to Python container system). It is something unique to Fedora as far as I know. Linux refuses to support SB because SB is a scheme to steal hardware ownership. The standard implementation is only a suggestion and bootloaders are not required to give you access to the custom keys implementation in the specification. Microsoft controls the shim for SB. It is extremely decisive and controversial.
“Linux” doesn’t support secure boot because it’s distributed as source rather than binaries. As far as I’m aware Linux actually has special handling for secure boot (there’s a kernel mode where it refuses to load unsigned drivers).
Also, I think as part of the secure boot spec, implementations are required to let you enroll your own keys. Whether that’s still true or if it even works on many motherboards is another question.
Anyway Unbuntu (and thus Mint) should take care of the signing for you. Although when I tried it didn’t work, but that could have because I use a fancy gamer kernel rather than the default.
The mechanism for not loading signed drivers is outside of the kernel. In Fedora, this is handled by Anaconda.
The last time I checked a few months ago, only Fedora and Ubuntu participate in the Microsoft 3rd party key signing arrangement. This shim signed aspect is done at the final stage of distro packaging. There is no upstream so it is not a Debian or downstream thing.
There can only be the one kernel they sign. This is a problem for Nvidia because Nvidia modules are unsigned upstream. They only do their binary BS and supply kernel source code that is different from that binary. We must build that source to make a module but this is unsigned. The only way to have Nvidia drivers under a shim is to build a system that can shim into the gap between boot and kernel init. This must build the Nvidia module from source in a way that is totally secure so that it may never be modified inside Linux or used as an entry point to add a root kit to the UEFI bootloader. Once the Nvidia module is built, then Linux is initialized. This is the only way to have secure boot functioning unless the user manually adds custom keys to the bootloader and signs their own kernel modules. Most distros leave this aspect of the system entirely up to the end user because it is not part of Linux. Most distros tell you to turn off secure boot. The bootloader is the largest attack surface in modern computers.
The secure boot specification is only a set of guidelines and not a required implementation. Indeed, my laptop does not have the functionality implemented to enable this, thus the reason I know all of this so well. There is still another way that I have not explored, but it is generally less known and lesser documented. There is a tool called Keytool that can boot directly into UEFI. Supposedly it can manually alter the keys outside of the bootloader implemented features set. The only documentation I have ever come across for Keytool is in the gentoo handbook, but gentoo documentation assumes a very high level of competence.
All distros “support” SB because SB is not part of Linux and it requires setting your own SB keys. That is outside of easy scope. The question is if they support the m$ signed shim and what system is used to achieve this. Fed uses Anaconda (unrelated to Python container system). It is something unique to Fedora as far as I know. Linux refuses to support SB because SB is a scheme to steal hardware ownership. The standard implementation is only a suggestion and bootloaders are not required to give you access to the custom keys implementation in the specification. Microsoft controls the shim for SB. It is extremely decisive and controversial.
“Linux” doesn’t support secure boot because it’s distributed as source rather than binaries. As far as I’m aware Linux actually has special handling for secure boot (there’s a kernel mode where it refuses to load unsigned drivers).
Also, I think as part of the secure boot spec, implementations are required to let you enroll your own keys. Whether that’s still true or if it even works on many motherboards is another question.
Anyway Unbuntu (and thus Mint) should take care of the signing for you. Although when I tried it didn’t work, but that could have because I use a fancy gamer kernel rather than the default.
The mechanism for not loading signed drivers is outside of the kernel. In Fedora, this is handled by Anaconda.
The last time I checked a few months ago, only Fedora and Ubuntu participate in the Microsoft 3rd party key signing arrangement. This shim signed aspect is done at the final stage of distro packaging. There is no upstream so it is not a Debian or downstream thing.
There can only be the one kernel they sign. This is a problem for Nvidia because Nvidia modules are unsigned upstream. They only do their binary BS and supply kernel source code that is different from that binary. We must build that source to make a module but this is unsigned. The only way to have Nvidia drivers under a shim is to build a system that can shim into the gap between boot and kernel init. This must build the Nvidia module from source in a way that is totally secure so that it may never be modified inside Linux or used as an entry point to add a root kit to the UEFI bootloader. Once the Nvidia module is built, then Linux is initialized. This is the only way to have secure boot functioning unless the user manually adds custom keys to the bootloader and signs their own kernel modules. Most distros leave this aspect of the system entirely up to the end user because it is not part of Linux. Most distros tell you to turn off secure boot. The bootloader is the largest attack surface in modern computers.
The secure boot specification is only a set of guidelines and not a required implementation. Indeed, my laptop does not have the functionality implemented to enable this, thus the reason I know all of this so well. There is still another way that I have not explored, but it is generally less known and lesser documented. There is a tool called Keytool that can boot directly into UEFI. Supposedly it can manually alter the keys outside of the bootloader implemented features set. The only documentation I have ever come across for Keytool is in the gentoo handbook, but gentoo documentation assumes a very high level of competence.