Defeating Secure Boot With Linux Kexec

[mrugiero]

Well, AFAIK, kernel modules are equally "dangerous", to put it in some way. Anyway, it is probably fixable. If you can make a software that only loads signed kernels, you probably can modify kexec and the module loading functions to work the same way.

Also, I have news for the ones celebrating this: if you get to run a Linux kernel, either you are running Android (AFAIK, they don't use UEFI, so SecureBoot is already out of the picture and the vendor lock-in has been achieved in some other way), or you already bypassed SecureBoot if that's what you wanted. So, this news is at best "meh" if you dislike SecureBoot, and it is bad (but fixable) if you consider it a feature. So there is no reason to party here.

[MWisBest]

Well, AFAIK, kernel modules are equally "dangerous", to put it in some way. Anyway, it is probably fixable. If you can make a software that only loads signed kernels, you probably can modify kexec and the module loading functions to work the same way.

Also, I have news for the ones celebrating this: if you get to run a Linux kernel, either you are running Android (AFAIK, they don't use UEFI, so SecureBoot is already out of the picture and the vendor lock-in has been achieved in some other way), or you already bypassed SecureBoot if that's what you wanted. So, this news is at best "meh" if you dislike SecureBoot, and it is bad (but fixable) if you consider it a feature. So there is no reason to party here.

Android can run on some x86 devices with SecureBoot last I heard, but the market for x86 devices is small, let alone ones with SecureBoot...

With ARM platforms, it uses the ARM TrustZone, which can basically serve the same purpose and more that SecureBoot does.

[curaga]

Can you by chance provide some references for this? I'd be very interested in it!

If this sounds like sarcasm or trolling, it isn't, I'm geniunely interested in reading about this... I just know it can be hard to tell on the internet about things like this sometimes, especially in places where trolling can be common like here.

Read up on grsecurity and Brad Spender; that quote was from Spender. I don't have an exact link, but it's not exactly secret info.

[MWisBest]

Read up on grsecurity and Brad Spender; that quote was from Spender. I don't have an exact link, but it's not exactly secret info.

Thank you very much, I'll have a look at it!

[Kano]

I do not fully understand what he means that the windows kernel can be started with kexec. Usally EFI/Microsoft/Boot/bootmgfw.efi is started, thats nothing special but a standard efi binary. I want a sample implementiation to see how it should work. I don't consider the ReatOS loader as valid windows loader example.

[movieman]

Protection from rootkits and malware control at the hardware interface layer?

Which I couldn't care about in the slightest, compared to the risk of hardware manufacturers locking me out of running the software I want to run on the hardware I've paid for.

[mjg59]

I do not fully understand what he means that the windows kernel can be started with kexec. Usally EFI/Microsoft/Boot/bootmgfw.efi is started, thats nothing special but a standard efi binary. I want a sample implementiation to see how it should work

You start the Windows kernel with kexec in exactly the same way that you start the Linux kernel with kexec - load it, generate the appropriate handoff data and jump to the entry point. kexec-tools has implementations for the kernel and multiboot files already, it wouldn't be that much work to implement Windows support.

I don't consider the ReatOS loader as valid windows loader example.

You don't consider something that can load and execute the Windows kernel as a valid example of something that can load and execute the Windows kernel? Interesting position.

[erendorn]

Which I couldn't care about in the slightest, compared to the risk of hardware manufacturers locking me out of running the software I want to run on the hardware I've paid for.

but then, locking you out doesn't require secureboot on ARM, and it's specifically non compliant for secureboot on x86. So you couldn't care less compared to "nothing", leaving you in an odd position to complain either way.

[IsacDaavid]

No that is totally against the GPL license.
You can't mix GPL and proprietary code.

But they already do this. The firmware folder in the Linux code base is plagued with binary blobs, and some of them explicitly include license information that forbids modification, etc.

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/firmware/WHENCE?id=refs/tags/v3.12.3

[bridgman]

But they already do this. The firmware folder in the Linux code base is plagued with binary blobs, and some of them explicitly include license information that forbids modification, etc.

I think that's why the firmware files don't actually get built into the Linux kernel, but instead are treated as data files.