Secure Boot

aut0exec · 2019-05-17 01:24:37

Greetings! I've been spending a decent amount of time looking into EFI-Stub loading and Secure boot. I'm hoping to find someone who may be able to help at this point as I'm not sure where to proceed. Full disclosure this whole project is currently just an academic endeavor! If I can get this working, I plan to document the process as much of the current documentation seems to assume everyone wants to use Shim and leave the MS certs on their box (seems like this would defeat the whole purpose of custom keys though, correct?).

I've managed to compile a kernel with EFI-Stub and get it to boot without Grub (quite awesome functionality, imo). Now I'm wanting to setup my own Secure Boot keys so that my system will only boot my signed kernel. This seemed like a pretty easy feat until starting down the road... At the moment, I'm able to generate and sign my own PK, KEK, and db. sbsign signs my kernel and sbverify states that it has a valid signature matching my db cert. I can then use KeyTool to 'install' the keys (db, KEK, PK - in that order) on the system without errors. Upon enabling secure boot in EFI, the system reboots to a blank screen and then ultimately errors out with 6 red LED flashes of the power light (according to HP this means no graphics).

The hardware is an HP Z420 workstation on the newest UEFI release with a Quadro K2000 GPU. I'm thinking it has something to do with OROMs but I'm not entirely sure. Was hoping that if I exported the original HP certs and concatenated/signed them with my custom ones I'd be good to go but apparently that's not the case.

The system will boot with the factory certs enabled and Shim available though. So it seems like something in the boot process might require MS' cert and it wouldn't surprise me if the nVidia card was the culprit. Long story short, has anyone been able to successfully purge MS certs and boot entirely from their own self signed certs?

If the commands run are needed, please let me know but I've been using the following resources primarily (obviously not following the gentoo/arch and shim/grub specific parts):

https://wiki.gentoo.org/wiki/Sakaki%27s … ecure_Boot
https://www.rodsbooks.com/efi-bootloade … ng-sb.html
https://wiki.archlinux.org/index.php/Secure_Boot

Head_on_a_Stick · 2019-05-17 07:52:59

Just FYI:

aut0exec wrote:

I've managed to compile a kernel with EFI-Stub

The stock Devuan kernels already have CONFIG_EFI_STUB enabled and the beowulf kernel images are signed with Microsoft's key.

In respect of your problem, have you enabled custom Secure Boot keys in your firmware ("BIOS") options?

The Debian wiki has a Secure Boot guide that may help:

https://wiki.debian.org/SecureBoot

FWIW the Debian buster RC1 installer fully supports Secure Boot albeit with Microsoft's keys.

aut0exec · 2019-05-17 14:55:16

Thanks HoS. Was aware of the CONFIG_EFI_STUB in Devuan/Debian kernels. Should have mentioned that this kernel is attempting to be small, specific, and without the need for an initramfs (again for 'fun', haha).

Secure boot Custom keys have been enabled on the firmware. That's what causes the machine to go into the flashing red light of death. It won't do that until I put the custom keys onto the system and enable secure boot in firmware.

Been looking into it more today and have been wondering if the kernel's modules aren't being signed during the build process? I am new to that whole process though. Have been reading about CONFIG_MODULE_SIG_* parameters today but I'm confusing myself I think.

Can I pass my db priv key and db crt to the kernel build process to have the kernel automatically sign itself and associated modules during the make process? The kernel docs seems to suggest so: https://www.kernel.org/doc/html/v4.19/a … gning.html but I'm not sure where to put the pem/crt files that I've already generated so the kernel build process uses them.

I suppose the other option is to just manually sign all of the modules after the kernel build process with the proper kmodsign command?

Sorry for all the questions but I do appreciate your help!

Head_on_a_Stick · 2019-05-18 16:29:47

aut0exec wrote:

have been wondering if the kernel's modules aren't being signed during the build process?

I'm not sure tbh, I'm happy using the stock Debian signed kernel in buster and I never managed to get custom keys working with my last UEFI laptop.

If you think the modules are the problem then try configuring the kernel without any modules at all (ie, with all the options built-in).

aut0exec · 2019-05-19 23:07:39

Head_on_a_Stick wrote:

If you think the modules are the problem then try configuring the kernel without any modules at all (ie, with all the options built-in).

Should've reported back on Friday. I did just this and still ran into the same issue. Without any sort of display, I can't see anything during system boot up with SB enabled and custom certs... So no idea how to troubleshoot this (thought maybe serial console but system doesn't have one of those either, figures...). Thought about a USB to serial adapter but not sure if it would work before Linux take over though. Any ideas?

I'm going to sacrifice my trusty Toshiba testing laptop to the Secure Boot deity and see if the nvidia card is the issues in the Z420 tower. This Toshiba appears to have integrated everything so I'm hoping that there won't be any crazy OROM's to deal with. I'll report back with the results.

aut0exec · 2019-05-21 00:00:58

Well good news the Toshiba worked! Was able to EFI-stub load without an initramfs and secure boot enabled. I'm hoping to repeat the steps on the HP workstation and see if I can get different results. Was shocked at how much simpler the Toshiba was than HP. Was able to do everything except toggle Secure Boot on in the Bios from within the CLI.

czeekaj · 2019-07-23 20:44:00

Any one with experience setting up their secure boot?

I have secure boot enabled on two systems. However, when I check the status it's either on setup mode or bios says it is off.
The laptop I have custom keys setup and loaded into the bios. However, I turn on secure boot in bios. It boots to grub. I check setting in the bios again and it's on. But, I can boot to usb and it mentions secure boot being off. The bios setting is set to on however, now with custom keys.

Acting as if it was off. When it's on with default keys. It stays on, and wont but into grub.

Not sure if I set it up properly having trouble finding a guide that has worked yet. Any one figure out how to set up custom keys on Devuan? I know every bios is a bit different but I may have missed a step. I get an error running on of the last commands on gentoo guide.
No efivarfs filesystem is mounted.

It's odd behaviour but with the proper packages, and grub installed.

grub-install --uefi-secure-boot --bootloader-id=debian

I can boot with secure boot on. However, boot behavior seems identical and status seems to be off. Even though it's on in the bios.

Last edited by czeekaj (2019-07-23 20:44:44)

seeker · 2019-09-02 00:44:21

I was wondering if it is worthwhile to convert my traditional boot install to a UEFI boot install. Not sure if there are any advantages.

ToxicExMachina · 2019-09-02 10:08:44

seeker wrote:

I was wondering if it is worthwhile to convert my traditional boot install to a UEFI boot install. Not sure if there are any advantages.

UEFI must die. That's all you need to know. The reason is: don't tie yourself to this defective technology. Overcomplication, vulnerability, malware-friendly environment, etc. - this is UEFI. If there will be no option but boot via UEFI it will be an inevitable evil - not a good thing.

aut0exec · 2019-09-04 01:31:15

seeker wrote:

I was wondering if it is worthwhile to convert my traditional boot install to a UEFI boot install. Not sure if there are any advantages.

I've been converting new installs to it but definitely not going back to switch MBR systems to UEFI unless absolutely necessary. Mainly just because of not wanting to switch the partitioning over.

In contrast to ToxicExMachina, I've enjoyed UEFI, there's a bunch of nice things about it (Secure Boot, efibootmgr, doing away with MBR partitions, etc), To each their own though. If you have a spare machine, try a new install and see what you think. You probably won't notice many differences until you start messing with the boot components (Grub mainly, haha).

czeekaj · 2020-01-12 00:08:06

aut0exec,
While I myself enjoy EFI booting. I enjoy being able to dual boot and partition up multiple hard drives and be able to easily not bork a boot loader using efibootmgr.
However, if you look at UEFI talks. It is full of binary blobs and non-free shenanigans, many have network stacks for instance. You also have to trust the manufactures firmware to respect your setting when you turn it off. Literally, watch your first steps. You know a lot goes on before you even get to good old grub and sysV init.
Not to mention with intel and amd virtualization. Management engine/ secure processor environment. There is nothing ensuring you should be trusting the manufacturer.
For instance. UEFI firmware is a lot more bloated as ToxicExMachina said.
It does have modern conveniences. However, if you want a free as possible system like Libreboot free, will work only with MBR booting.

When I back up Iso for a USB, I like to have it EFI ready because mbr install on a Uefi system means your going to have to wipe something out.

Last edited by czeekaj (2020-01-12 00:14:49)

Head_on_a_Stick · 2020-01-12 11:10:32

czeekaj wrote:

You also have to trust the manufactures firmware to respect your setting when you turn it off.

In respect of UEFI, it is not possible to "turn it off" — all you can do is enable CSM ("Legacy" mode), which still runs the boot process through the UEFI firmware but subjects it to an extra added abstraction layer which is probably full of even more bugs.

Secure Boot should help with some of the problems introduced by UEFI so you should use that rather than CSM.

aut0exec · 2020-01-12 14:45:14

Head_on_a_Stick wrote:

In respect of UEFI, it is not possible to "turn it off" — all you can do is enable CSM ("Legacy" mode), which still runs the boot process through the UEFI firmware but subjects it to an extra added abstraction layer which is probably full of even more bugs.

Even saw some Dells the other day where CSM isn't an option within the firmware! Figured at some point everyone would move over from CSM/Legacy just wasn't sure when.

Czeekaj - I unfortunately don't have the ability to build my own chips, PCB's, FPGA's, and what not so I'm sort of stuck trusting hardware vendors at a certain point. Secure boot at least makes the bar for high jacking my system 'a little bit' more difficult!

Head_on_a_Stick · 2020-01-13 16:01:25

aut0exec wrote:

Even saw some Dells the other day where CSM isn't an option within the firmware!

Yeah, Intel are planning to remove it completely: https://www.anandtech.com/show/12068/in … fi-by-2020

Bastards...

sgage · 2020-01-13 17:27:06

Head_on_a_Stick wrote:

aut0exec wrote:
Even saw some Dells the other day where CSM isn't an option within the firmware!
Yeah, Intel are planning to remove it completely: https://www.anandtech.com/show/12068/in … fi-by-2020
Bastards...

Is this still the timeline for eliminating CSM? (The article was written in 2017.)

Head_on_a_Stick · 2020-01-13 17:28:14

^ I don't know, the article was linked over at the MX forums last week and that was the first I'd heard of it.

ToxicExMachina · 2020-01-15 06:59:19

Head_on_a_Stick wrote:

aut0exec wrote:
Even saw some Dells the other day where CSM isn't an option within the firmware!
Yeah, Intel are planning to remove it completely: https://www.anandtech.com/show/12068/in … fi-by-2020
Bastards...

Intel can go screw itself: https://www.seabios.org/Build_overview# … _.28CSM.29

czeekaj · 2020-01-29 09:24:25

is cbios a decent option? Because what it looks like is it still will have binary blobs and if you don't you probably could of just used libre boot however, building an image for your hardware doesn't seem easy. Only time I can flash something embedded is with the same image or with one someone else built, but your Bios is 16 bit. Which does make it sound appealing. Open Source Proprietary Software looks like Purism's laptops coreboot system is decently robust. so cbios seems like a low tech abstraction from ME region of bios to the operating system. IBM does appear to be the most sane option when it comes to picking CPU these days. OpenWRT is good but who knows what binary blobs they needed to get it running on the hardware.

As for secure boot, I can't seem to find a good guide or documentation for a Dell setup. I have my own keys generated and loaded into the bios. (before it wouldn't boot with secure boot on)

Now it boots, but it boots USB as well. With custom keys it seems to just boot as if it was off. I guess I didn't set it up quite right. Might try again and update this if I have better luck. Dell seems like they could make really good products. But then there is just something about their bios that scares you right away. Anything Post-skylake I don't really want to dip into.

Last edited by czeekaj (2020-01-29 09:54:12)

aut0exec · 2020-02-08 18:31:26

czeekaj wrote:

Now it boots, but it boots USB as well. With custom keys it seems to just boot as if it was off. I guess I didn't set it up quite right. Might try again and update this if I have better luck. Dell seems like they could make really good products. But then there is just something about their bios that scares you right away. Anything Post-skylake I don't really want to dip into.

I've not experimented with my dells yet but my Toshiba Satellite was simply as easy as loading my custom keys, building a stub-load kernel, signing it, and then enabling secure boot in the bios. Will be interested in what you find out with your Dells though.

czeekaj · 2020-03-23 17:08:38

I think it's possible. The bios has ways to custom load keys, I just might not know what I'm doing. Do you have any good documentation maybe could point me in right direction?

I think I just missed a few steps, I followed a couple guides at the same time. Got all the keys built and signed the grub.efi However, shrugs* doesn't seem to be working as expected. The grub.efi.signed I can boot from, but behaviour seems no different then if secure boot is off. Which it tells me it is off in boot menu after I just turned it on.

Thanks

My next experiment will be to try Secure boot on my Asus Motherboard,

PS: Fun fact. I saw a post on a debian thread regarding Nvidia persistenced.
I thought this was a devuan issue. Got no answers however, turns out the user got it running by turning off secure boot in Bios. Which I refuse to run nvidia drivers anyway anymore.

Last edited by czeekaj (2020-03-23 17:13:28)

The officially official Devuan Forum!

#1 2019-05-17 01:24:37

Secure Boot

#2 2019-05-17 07:52:59

Re: Secure Boot

#3 2019-05-17 14:55:16

Re: Secure Boot

#4 2019-05-18 16:29:47

Re: Secure Boot

#5 2019-05-19 23:07:39

Re: Secure Boot

#6 2019-05-21 00:00:58

Re: Secure Boot

#7 2019-07-23 20:44:00

Re: Secure Boot

#8 2019-09-02 00:44:21

Re: Secure Boot

#9 2019-09-02 10:08:44

Re: Secure Boot

#10 2019-09-04 01:31:15

Re: Secure Boot

#11 2020-01-12 00:08:06

Re: Secure Boot

#12 2020-01-12 11:10:32

Re: Secure Boot

#13 2020-01-12 14:45:14

Re: Secure Boot

#14 2020-01-13 16:01:25

Re: Secure Boot

#15 2020-01-13 17:27:06

Re: Secure Boot

#16 2020-01-13 17:28:14

Re: Secure Boot

#17 2020-01-15 06:59:19

Re: Secure Boot

#18 2020-01-29 09:24:25

Re: Secure Boot

#19 2020-02-08 18:31:26

Re: Secure Boot

#20 2020-03-23 17:08:38

Re: Secure Boot

Board footer