Getting Secure Boot to work

boot
iso
secure-boot

#1

So… Resuming from my findings in the previous thread as of now there are only 2 alternatives:

  • continuing using efitools unsigned package
  • rolling back to preloader-signed (which even though may cause problems in some older UEFI systems)

As for first idea, tbh at that point it may also be removed as well, since it provides really no purpose (as it seems was done in 17.0.1).
On the other hand the second one may cause some problem with a few older pre-Win8 UEFI systems (which should be a pretty slim minority by now), but on the upside the majority of users out there should just need <10 seconds to boot any ISO up now.

As I was saying, I posted on jejb blog (last time I got in touch with him a bit more “directly”, he seemed a bit upset by that) but he still hasn’t answered.


Then, in theory I guess like archiso (or manjaro-tools) could even get their own signature, but I’m not suggesting anybody to spend their precious money.

Last but not least, arch wiki does also mention Fedora’s shim… But I have really no experience with it.
p.s. a secure-boot tag wouldn’t hurt


Can Manjaro operate OK if the secure boot is on?
Bootable USB resulting in 'invalid signature'
Secure Boot with rEFInd
#2

I used the arch wiki later part to sign my own keys and did mange to get manjaro to boot had to change some things in the singing of the bootloader and the kernel as manjaro’s setup is different to arch. Give it a go and I will be happy to help if you get stuck.


#4

I have secure boot with self signed custom keys enabled by the manufacturer as an option in the BIOS. It clears the factory default Microsoft signed keys and apparently the hardware generates new machine specific keys or at least it appears to, because secure boot is enabled and everything appears to works as intended. Hitting reset in the BIOS resets it to factory keys. Pretty neat, and actually easy. Mind you I also have power on passwords and every security feature enabled, along with hardware encryption on the ssd. In this case it is a Lenovo Thinkpad Yoga 11e running Archlinux. I am guessing other Thinkpads have similar features.


#7

Yes, I know about self-signing (the second part of the wiki page)… Though, arguably that’s not what an “Enjoy the simplicity” distro wants OOTB :wink:

I also guess this isn’t really the most proper place to discuss about this (I mean… having upstream arch doing it would be well regarded), and I’d try to raise a point on (not sure if ArchISO or efitools)… But so badly ended last thread that I had to open this.
Though having just found out the whole story, and seeing @artoo is/was on a killing spree… I was hoping somebody informed (or with the right contacts) could shed some light on before I went on disturbing big guys.


#8

Could you write instructions in the tutorial section please? This would be make it more accessible approach for more people.


#9

For a simple secure boot setup I think we would need at least

  • sbupdate (maybe tweaked?) to automatically sign kernels on update
  • shim-signed/something

Anyway, it seems to me that if we want to make secure boot accessible for beginners (if that is even possible… ), we would need a new maintainer to work on the matter.


#10

I could but not sure when, as have mislaid my notes for this and would probably have to start from scratch. At least I know it does work so perhaps not so hard this time.

Good news I found my notes it is basically the arch wiki with a few things changed for manjaro
sometime this week I will try it again

#11

Here you go have fun
Install the following packages “efitools” “sbsigntools”

In a terminal

uuidgen --random > GUID.txt

openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl

openssl req -newkey rsa:2048 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db.crt
openssl x509 -outform DER -in db.crt -out db.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.es

Open /boot/efi/EFI/boot/ as root and Copy grubx64.efi somewhere safe.

Open /boot/efi/EFI/boot/ as root and Rename grubx64.efi to grubx64_old.efi

sudo sbsign --key db.key --cert db.crt --output /boot/efi/EFI/boot/grubx64.efi /boot/efi/EFI/boot/grubx64_old.efi

Put firmware in "Setup Mode"
Secure Boot is in Setup Mode when the Platform Key is removed. To put firmware in Setup Mode, enter firmware setup utility and find an option to delete or clear certificates.
Enroll keys in firmware
Copy all *.cer, *.esl, *.auth to a FAT formatted file system (you can use EFI System Partition).
Launch firmware setup utility or KeyTool and enroll db, KEK and PK certificates.
If the used tool supports it prefer using .auth and .esl over .cer.

I used the first part of this guide http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil

  1. Unload all keys
  2. Load stock for dbx,db and KEK
  3. Append your keys to db and KEK
  4. Load your key to PK

Note in 2. apart from dbx the other two are not needed unless you are running Windows

On first boot manjaro-P4 would not boot but I could boot UEFI-OS-P4 partition to the grub menu and then it booted
On a reboot manjaro_P4 would boot again and the partition does not.

@mirh @Chrysostomus

Will make this a tutorial but only when other people confirm it works for them too.


rEFInd instead of GRUB2?
#12

Mhh… Perhaps I didn’t explain it clear enough (or maybe it’s just obvious if you came from the other thread), but with this thread I was hoping to get some of the Manjaro dev team to acknowledge that atm there’s a huge accessibility blocker for basically everybody with an OEM computer bought in the last year and half.

I’m pretty confident your method is gonna work (this automating it perhaps?), but that’s hardly going to help anybody but a few enthusiasts.


#13

No, everybody understood and you are right. I was just asking off topic question.


#14

Actually you may not have noticed, but in manjaro at least, I have not found it necessary to sign kernels.
Secure boot seems to work (not sure how to prove it) by only signing the boot loader.

If you wish to sign the kernel do the same copy and rename as above.

sudo sbsign --key db.key --cert db.crt --output /boot/vmlinuz-4.9-x86_64 /boot/vmlinuz_old-4.9-x86_64

To sum up Secure Boot works fine with Manjaro with or without the kernel signed.
The problems are that you cannot boot a live system with secure boot enabled just disabled secure boot and everything still works so perhaps not really a problem just enable or disable depending on what you need to do.


#15

Hmm, no volunteers in dev team it seems.

In my view, its absurd to implement something that actively tries to lock out non MS world.
I find it the wrong solution to give in to the demands, instead of refusing to buy such computers.
In the end, the user digs his own grave with such behavior, because the user has it in his inventory to actively pursue a different course, with his purse.


#16

The question is: who’s the only “constant and authority” in x86 world?
And there you have that necessarily such a arguably useful feature had to pass through them.

Anyway, I see no volunteers means you had no specific plan/knowledge in this regard, so I opened an issue upstream https://bugs.archlinux.org/task/53864


#17

Would not influence manjaro at all.
We don’t use arch build tools.


#18

Well, seems like you still use their repositories after all because when they dropped it you immediately followed. :wink:


#19

Sounds like a conspiracy theory to me.
We recently changed to grub on iso, not even thinking about secure boot, it has not been on the table at all.


#20

??
This I was talking about happened a year ago (see first link in OP).

Thanks for explaining why now even unsigned BL is no more.


#21

I thgink you mixed up stuff here.
Look, the gummiboot has been swapped with grub on iso.
Hence, the request you filed on arch tracker won’t be on manjaro install media, since they don’t use gummiboot(systemd-boot).


#22

I think your grammar is mixed up, since first you say gummiboot has been replaced with grub on [our?] iso (which I have seen), then you say they aren’t using gummiboot.

Anyway, LF preloader is no bootloader specific (contrarily to Fedora shim), so I don’t see the problem.


#23

The is referring to manjaro install media, used in plural sense, I believe.