Errors while enrolling keys (chattr & PK permissions issues)

[in0ni]

First of all, I want to mention that your dotfiles was a great source of learning for me a few years back, so thank you! I still check it once in a while to discover something new :)

I've used arch-secure-boot in the past without any issues. I recently needed to setup everything again, have followed the same process as before, indicated in your read me (setting bios password, clearing keys) -- but enrolling no longer works due to the following errors:

Enrolling Secure Boot keys...
chattr: Invalid argument while trying to stat /sys/firmware/efi/efivars/PK*
chattr: Invalid argument while trying to stat /sys/firmware/efi/efivars/KEK*
chattr: Invalid argument while trying to stat /sys/firmware/efi/efivars/db*

The files do not exist until sbkeysync is executed.

After digging around I was able to do the following to get the db/KEK enrolled (no chattr required), from wiki:

# sbkeysync --keystore /etc/secureboot/keys --verbose

Though after running sbkeysync --keystore /etc/secureboot/keys --verbose --pk I get the following error:

....
Inserting key update /etc/secureboot/keys/PK/PK.auth into PK
Error writing key update: Permission denied
Error syncing keystore file /etc/secureboot/keys/PK/PK.auth

I then tried manually running these:

# chattr -i /sys/firmware/efi/efivars/PK*
# efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK

But the following error indicates that perhaps chattr is no longer necessary and perhaps problematic:

Cannot write to PK, wrong filesystem permissions

Once I do reset the file permissions back with chattr +i I get the error:

Failed to update PK: Operation not permitted

This last error, and enrolling the PK key, isn't related to your script... I have tried several things:

• using KeyTool (get error 26 "security violation")
• using cert-to-efi-sig-list and sign-efi-sig-list as on the wiki...
• following the tips on the wiki regarding the password issue... and no luck

I think chattr is perhaps no longer needed.

Any ideas why I cannot enroll PK? I would greatly appreciate any advice/guidance. I'm on a Thinkpad X1 Gen 9, and again had no issue before... but now I'm stuck and have spent several hours trying to figure this out.

Thank you in advance.

[max-baz]

Hello! Thanks for the kind words, and the detailed description!

While I don't have any immediate ideas, I wanted to ask if you also tried to reboot and load the UEFI settings screen, and check what you can do from there - maybe you can enroll keys from that UI? I found somewhere that the path on some Lenovos might be "Security > Secure Boot > Key Management".

[in0ni]

Wow... I did not think I could edit them there. I just thought it was informative... ugh, "Management"... think I should have taken a break. Worked like a charm, thank you!

[max-baz]

I'm happy that you found a solution! As for whether chattr -i is needed or not, in theory it should not harm as long as files are present, but enroll is certainly an operation that is getting tested very rarely... And it sounds like on your laptop the root cause for not being able to update them lies somewhere else anyway... So I am not sure if we should do something about it, or leave that section as is until we have more data from other people 🤔

[in0ni]

To be honest this is out of my area of experience (clearly, lol). What is odd is that I previously did this, on two separate occasions (a while back) with this same laptop without issues. This third time around something changed, perhaps a firmware update.

Perhaps it's suitable to test if the files exist before chattr to at least allow it to continue and not fail? What is also interesting is the "wrong file permissions" which was solved by setting it back to +i.

Anyway, I leave it to your best judgement. I can't afford much additional feedback. Thanks again.

[ShellCode33]

Something that might be worth adding to the readme is a mention to the setup mode which allows you to enroll keys from userland and is part of the UEFI spec.

The setup mode can usually be turned on in the BIOS by disabling the secure boot and removing the existing keys from the key manager. But it depends on the UEFI implementation written by the manufacturer, and from my tiny experience but also from what I've read about it on the internet, most of the time UEFI implementations are broken. In such cases, falling back to enrolling the keys manually from the BIOS is usually the only thing that works.

[max-baz]

and from my tiny experience but also from what I've read about it on the internet, most of the time UEFI implementations are broken.

Hehe it's also my own experience 😄

If you'd like to send a PR with a note about this, please do! I'll do add something otherwise when I get a chance. Thanks, it's a good idea!

[ShellCode33]

Well sorry but I don't feel like sending a PR right now. But at least if someone else end up reading this, they will be aware that the setup mode is a thing!

[in0ni]

I wouldn't mind creating a PR -- but to be honest, the README already mentions this... although not quite specific: by deleting the keys it enters setup mode. In my case, this was not the issue as I was already in setup mode. I can do this by either deleting the keys (enters setup mode automatically) -- or by a specific option to enter setup mode.

I still have a feeling, from what I just encountered -- which was working fine over a year ago that I used this on the same device -- that maybe something changed with this chattr -i business (or my firmware, an update or bug?). Also how the files are not existent until sbkeysync is executed, which clearly was not the case before.

[max-baz]

You are right that it is implicitly mentioned, but whatever we can document that can help people to enroll if they get stuck, is a valuable addition. How does this look? 221384c Feel free to propose changes. Regardless of what we end up doing with chattr or sbkeysync, at least people would have an easier time to try to find a workaround to proceed?

[in0ni]

Great addition regarding placing file in ESP!

[tomschulze]

I experienced the exact same issue on a Lenovo X250 with latest firmware installed (1.42). I solved it by following the workaround in the arch wiki. Thanks for adding this to the readme.

arch-secure-boot initial-setup
sbkeysync --keystore /etc/secureboot/keys --verbose

# this one throws a permission error. without it, the following commands still fail.
sbkeysync --keystore /etc/secureboot/keys --verbose --pk

# without chattr -i efi-updatevar would fail, too
chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*
efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK

To my surprise I had to install efitools to run efi-updatvar. Shouldn't this be included in arch-secure-boot's dependencies (as it's called in enroll-keys)? Or did I miss something?

[max-baz]

I suppose you are right, it was probably pulled as a transitive dependency before. Thanks for catching!

I would like to find a maintainer for the AUR package, as I don't run Arch myself right now (#34).