If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Secure Boot Breaks Kexec, Hibernate Support On Linux

Phoronix: Secure Boot Breaks Kexec, Hibernate Support On Linux

A set of "controversial" patches were published by Matthew Garrett this morning for the Linux kernel. One of the patch series will disable the kernel's support for kexec and hibernate support when running in a UEFI Secure Boot environment...

Basically Secure Boot with physical access to the system is a joke anyway for several reasons:

a) You can boot Ubuntu (but not Kubuntu), Fedora and whatever other distro that ships binaries with MS key - then feel free do modifiy whatever you like.

b) If you use mjg59's shim to add a key/hash it was impossible for me to reset this without reflashing the firmware to a state before. When added it is in for all times (tested with ami uefi - one of the boards tested was an asrock b75 board). So it will always accept your efi binaries.

c) Some boards like Asrock keep the CSM enabled by default even with Secure Boot on (btw. would you search it under ACPI options???) - just boot via a normal loader.

d) Even if you don't have a SB enabled iso you can just switch it off in 99% of all cases because there is no firmware password set anyway.

Even if you only allow signed kernels to be booted from hd you would need to encrypt it. And what protects you from a modified initrd? Maybe it would be more useful to sign that with a personal key, set a uefi password (if it helps - i know boards with password skip jumper...). A tiny bit hard could be a password set on the hd, but when suspend is used that password if often stored as well. Better forget security on local pcs

Secure Boot is all about protecting against longterm remote exploits (Someone hacks you and replaces a kernel module that you use with one that has a backdoor, or something along those lines) If they've got physical access...you got screwed long before they sat down at your desk.

Or is Secure Boot all about protecting Microsoft's longterm revenue stream. Keep in mind that up-front the article didn't buy into the security of Secure Boot. They were looking at taking these actions in order to prevent their key from being revoked from Microsoft. When the playing field appears crooked, due diligence becomes all the more important.

Or is Secure Boot all about protecting Microsoft's longterm revenue stream. Keep in mind that up-front the article didn't buy into the security of Secure Boot. They were looking at taking these actions in order to prevent their key from being revoked from Microsoft. When the playing field appears crooked, due diligence becomes all the more important.

Secure Boot's a tool, the wielder chooses how that tool is handled. If Microsoft wants to use Secure Boot for evil, fine, but don't blame Secure Boot. Blame Microsoft for making that choice.

Secure Boot is all about protecting against longterm remote exploits (Someone hacks you and replaces a kernel module that you use with one that has a backdoor, or something along those lines) If they've got physical access...you got screwed long before they sat down at your desk.

Crackers have better things to do. "Secure" Boot being a thing to make installing Linux and other OSes harder is bigger than a big ass.

All you need to do is to sign your grub loader (i would like when gummiboot would work as well) - creating it is a bit tricky. I compiled grub2 from ubuntu and then signed the cd efi binary from the amd64.tar.gz in my first test. Basically you gain nothing that way, it just starts with Secure Boot enabled as it does not check for any signed kernels like when you use the precompiled grub-efi-amd64-signed (together with shim-signed) from Ubuntu.