Setup Mode still shows: Enabled after sbctl enroll-keys about sbctl HOT 33 CLOSED

There is no errors? Did you reboot and enable secure boot?

Ensure your boot loader is signed before you do that though.

from sbctl.

No errors.

$ sbctl enroll-keys
==> Syncing /usr/share/secureboot/keys to EFI variables...
==> Synced keys!

Yes, I did reboot and secure boot is enabled in bios.

$ sbctl verify
==> Verifying file database and EFI images in /boot...
  -> /boot/linux.efi is signed

Please note, linux.efi is a dracut generated efi image.

from sbctl.

Output of sudo sbkeysync --verbose please

from sbctl.

$ sudo sbkeysync --verbose

Filesystem keystore:
  /usr/share/secureboot/keys/db/db.key [3272 bytes]
  /usr/share/secureboot/keys/db/db.pem [1704 bytes]
  /usr/share/secureboot/keys/db/db.auth [3284 bytes]
  /usr/share/secureboot/keys/db/db.der [1218 bytes]
  /usr/share/secureboot/keys/db/db.der.esl [1262 bytes]
  /usr/share/secureboot/keys/KEK/KEK.auth [3281 bytes]
  /usr/share/secureboot/keys/KEK/KEK.pem [1716 bytes]
  /usr/share/secureboot/keys/KEK/KEK.key [3272 bytes]
  /usr/share/secureboot/keys/KEK/KEK.der [1227 bytes]
  /usr/share/secureboot/keys/KEK/KEK.der.esl [1271 bytes]
  /usr/share/secureboot/keys/PK/PK.pem [1708 bytes]
  /usr/share/secureboot/keys/PK/PK.der.esl [1263 bytes]
  /usr/share/secureboot/keys/PK/PK.auth [3273 bytes]
  /usr/share/secureboot/keys/PK/PK.der [1219 bytes]
  /usr/share/secureboot/keys/PK/PK.key [3272 bytes]
Invalid key /usr/share/secureboot/keys/PK/PK.pem
 - unknown cert type
Invalid key /usr/share/secureboot/keys/PK/PK.der.esl
 - unknown cert type
Invalid key /usr/share/secureboot/keys/PK/PK.der
 - unknown cert type
Invalid key /usr/share/secureboot/keys/PK/PK.key
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.pem
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.key
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.der
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.der.esl
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.key
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.pem
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.der
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.der.esl
 - unknown cert type
firmware keys:
  PK:
  KEK:
    /C=Key Exchange Key
  db:
    /C=Database Key
  dbx:
    0000000000000000000000000000000000000000000000000000000000000000
filesystem keys:
  PK:
    /C=Platform Key
     from /usr/share/secureboot/keys/PK/PK.auth
  KEK:
    /C=Key Exchange Key
     from /usr/share/secureboot/keys/KEK/KEK.auth
  db:
    /C=Database Key
     from /usr/share/secureboot/keys/db/db.auth
  dbx:
New keys in filesystem:
 /usr/share/secureboot/keys/PK/PK.auth

from sbctl.

As you can see the PK key isn't enrolled into the firmware.

Try sudo sbkeysync --verbose --pk

from sbctl.

$ sudo sbkeysync --verbose --pk

Filesystem keystore:
  /usr/share/secureboot/keys/db/db.key [3272 bytes]
  /usr/share/secureboot/keys/db/db.pem [1704 bytes]
  /usr/share/secureboot/keys/db/db.auth [3284 bytes]
  /usr/share/secureboot/keys/db/db.der [1218 bytes]
  /usr/share/secureboot/keys/db/db.der.esl [1262 bytes]
  /usr/share/secureboot/keys/KEK/KEK.auth [3281 bytes]
  /usr/share/secureboot/keys/KEK/KEK.pem [1716 bytes]
  /usr/share/secureboot/keys/KEK/KEK.key [3272 bytes]
  /usr/share/secureboot/keys/KEK/KEK.der [1227 bytes]
  /usr/share/secureboot/keys/KEK/KEK.der.esl [1271 bytes]
  /usr/share/secureboot/keys/PK/PK.pem [1708 bytes]
  /usr/share/secureboot/keys/PK/PK.der.esl [1263 bytes]
  /usr/share/secureboot/keys/PK/PK.auth [3273 bytes]
  /usr/share/secureboot/keys/PK/PK.der [1219 bytes]
  /usr/share/secureboot/keys/PK/PK.key [3272 bytes]
Invalid key /usr/share/secureboot/keys/PK/PK.pem
 - unknown cert type
Invalid key /usr/share/secureboot/keys/PK/PK.der.esl
 - unknown cert type
Invalid key /usr/share/secureboot/keys/PK/PK.der
 - unknown cert type
Invalid key /usr/share/secureboot/keys/PK/PK.key
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.pem
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.key
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.der
 - unknown cert type
Invalid key /usr/share/secureboot/keys/KEK/KEK.der.esl
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.key
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.pem
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.der
 - unknown cert type
Invalid key /usr/share/secureboot/keys/db/db.der.esl
 - unknown cert type
firmware keys:
  PK:
  KEK:
    /C=Key Exchange Key
  db:
    /C=Database Key
  dbx:
    0000000000000000000000000000000000000000000000000000000000000000
filesystem keys:
  PK:
    /C=Platform Key
     from /usr/share/secureboot/keys/PK/PK.auth
  KEK:
    /C=Key Exchange Key
     from /usr/share/secureboot/keys/KEK/KEK.auth
  db:
    /C=Database Key
     from /usr/share/secureboot/keys/db/db.auth
  dbx:
New keys in filesystem:
 /usr/share/secureboot/keys/PK/PK.auth
Inserting key update /usr/share/secureboot/keys/PK/PK.auth into PK
Can't create key file /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c: Operation not permitted
Error syncing keystore file /usr/share/secureboot/keys/PK/PK.auth

from sbctl.

lsattr /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c, if there is an i on that line, run chattr -i /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c and run the command again.

from sbctl.

Same error after chattr -i command (lsattr gave i in the output)

Inserting key update /usr/share/secureboot/keys/PK/PK.auth into PK
Error writing key update: Invalid argument
Error syncing keystore file /usr/share/secureboot/keys/PK/PK.auth

from sbctl.

Nice quirks. Reset your keys again. Ensure all the PK-*, KEK-* and db-* files don't have the i attribute set.

I'm unsure if this is an UEFI quirk with your motherboard or what it is.

from sbctl.

@Foxboron my motherboard (MSI laptop) seemed to have the same quirks.

from sbctl.

Can you describe what you are doing?

from sbctl.

Nothing fancy, enter setup mode, create keys, attempt to enroll, fail, chattr, attempt enrollment again, succeed.

There was another tool I came across (don't remember the name) that also did key creation and enrollment (used it in a previous arch install), but it was meant for use in an encrypted ESP. I don't remember it having that issue.

from sbctl.

For the record I had to unset i on /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c too on Dell XPS 13 (9310) for enroll-keys to work.

from sbctl.

Yep.

I think sbctl should check for the attribute before enroll and give back a sensible error message. I don't think it should chattr -i on all the files and think it's fine considering previous UEFI bugs.

from sbctl.

Good point 👍 Actually even adding a note (about chattr -i or a link to this issue) when an error is encountered would be very helpful (it took me some time to connect the dots ;) ).

from sbctl.

I think I have the same issue as @barmadrid in his comment above, i.e. the i attr is set on the PK-* files, but even after chattr -i on PK-* sbkeysync --verbose --pk failed with

Inserting key update /usr/share/secureboot/keys/PK/PK.auth into PK
Error writing key update: Invalid argument
Error syncing keystore file /usr/share/secureboot/keys/PK/PK.auth

Curiously though all other keys get enrolled by sbkeysync; only the PK fails.

I can set it in KeyTool.efi though, and also directly with efi-updatevar -f /usr/share/secureboot/keys/PK/PK.auth PK from a running Linux, so it doesn't seem to be a firmware issue per se.

See this gist for the complete output and all commands.

from sbctl.

Hmm, maybe sbkeysync is having issues :/

from sbctl.

I realized something!

Why do all these have the common problem of dbx: 0000000000000000000000000000000000000000000000000000000000000000 being a thing?
It should be completely empty! Can someone check if the actual file is all null bytes and how long they are? Either upload the file or throw it into xxd

from sbctl.

@Foxboron Which file do you mean? Sorry, I'm not familiar with EFI, so I'm not sure how to map dbx from sbkeysync to a file.

Are you referring to dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f in /sys/firmware/efi/efivars?

from sbctl.

Yes, if you look at your paste it's all null bytes.

https://gist.github.com/lunaryorn/75443ae3899d17093f7d6cfaa28d636a#file-gistfile1-txt-L61

from sbctl.

I'll check

from sbctl.

@Foxboron Doesn't look empty:

$ hexyl -v < dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
┌────────┬─────────────────────────┬─────────────────────────┬────────┬────────┐
│00000000│ 27 00 00 00 26 16 c4 c1 ┊ 4c 50 92 40 ac a9 41 f9 │'000&•××┊LP×@××A×│
│00000010│ 36 93 43 28 4c 00 00 00 ┊ 00 00 00 00 30 00 00 00 │6×C(L000┊00000000│
│00000020│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 00 00 00 00 │00000000┊00000000│
│00000030│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 00 00 00 00 │00000000┊00000000│
│00000040│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 00 00 00 00 │00000000┊00000000│
└────────┴─────────────────────────┴─────────────────────────┴────────┴────────┘

See more details, and dbx.gz (not a gzip actually, but the raw contents but Github wouldn't let me upload without a proper extension).

Edit: PS: This is after erasing the entire secure boot state in the firmware UI. Note that no other EFI var about secure boot exists, save this dbx file.

I've also uploaded the dmidecode output on the affected system; perhaps it helps.

from sbctl.

It is, actually. 27 is the attribute bytes. the next is the UUID ('ish) of the signaure list, and 30 denotes the size (I think). It's essentially an empty efi_signature_list which shouldn't be there. And sbkeysync dislikes it which is why it prevents you from inserting the PK.

from sbctl.

Indeed, I also see this empty signature list in KeyTool and the firmware UI.

I can remove it in the firmware UI or in KeyTool but it gets added again immediately on reboot (i.e. removing it and rebooting into the firmware interface directly already made it appear again), and removing it made things worse, I guess. sbkeysync still didn't work (same error as far as I could see), but now even efi-updatevar stopped working, with an "Invalid Argument" error. Sorry, don't have further details as I was in a bit of a hurry.

If it's relevant I can go through a reset again, remove the empty list, and try to enroll again and collect detailed information.

from sbctl.

For the record my dbx is not empty at all:

# sbkeysync --verbose
...
  db:
    /C=Database Key
    /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
    /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011
    /C=USA/ST=TX/L=Round Rock/O=Dell Inc./CN=Dell Bios FW Aux Authority 2018
    /C=USA/ST=TX/L=Round Rock/O=Dell Inc./CN=Dell Bios DB Key
  dbx:
    10d45fcba396aef3153ee8f6ecae58afe8476a280a2026fc71f6217dcf49ba2f
    32f5940ca29dd812a2c145e6fc89646628ffcc7c7a42cae512337d8d29c40bbd
    39dbc2288ef44b5f95332cb777e31103e840dba680634aa806f5c9b100061802
    e19dae83c02e6f281358d4ebd11d7723b4f5ea0e357907d5443decc5f93c1e9d
    b92af298dc08049b78c77492d6551b710cd72aada3d77be54609e43278ef6e4d
    81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86
    45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e
    64575bd912789a2e14ad56f6341f52af6bf80cf94400785975e9f04e2d64d745
    939aeef4f5fa51e23340c3f2e49048ce8872526afdf752c3a7f3a3f2bc9f6049
    3b0287533e0cc3d0ec1aa823cbf0a941aad8721579d1c499802dd1c3a636b8a9
    c83cb13922ad99f560744675dd37cc94dcad5a1fcba6472fee341171d939e884
    77dd190fa30d88ff5e3b011a0ae61e6209780c130b535ecb87e6f0888a0b6b2f
    55b99b0de53dbcfe485aa9c737cf3fb616ef3d91fab599aa7cab19eda763b5ba
    ca171d614a8d7e121c93948cd0fe55d39981f9d11aa96e03450a415227c2c65b
... quite a lot of these...
    c5d9d8a186e2c82d09afaa2a6f7f2e73870d3e64f72c4e08ef67796a840f0fbd
    f52f83a3fa9cfbd6920f722824dbe4034534d25b8507246b3b957dac6e1bce7a
    80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
    /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows PCA 2010
filesystem keys:
...

from sbctl.

@wiktor-k Yes, that seems like you are applying the revocation database published by uefi.org. That shouldn't cause any issues with sbkeysync, but it's weird it's not empty when the variables have been recently cleared for usermode.

from sbctl.

I have no idea if anyone knows that this works, but I went crazy having this same issue and using efitools to manually enroll the keys worked for me, just with these commands:

efi-updatevar -f /usr/share/secureboot/keys/db/db.auth db
efi-updatevar -f /usr/share/secureboot/keys/KEK/KEK.auth KEK
efi-updatevar -f /usr/share/secureboot/keys/PK/PK.auth PK

from sbctl.

Yes that work if you have the case where your firmware vendor enroll some bogus EFI variable into dbx. Most of this issues are going away when we move to my library. Sadly we just need to deal with it for the time being.

from sbctl.

Just a quick update:
I upgraded to desktop PC (now Gigabyte B450i board) and I no longer have this issue. Signed and enabled!
My old laptop with this issue was Lenovo.
Thanks for your work.

from sbctl.

I'll close it then :) Thanks! A lot has happened to the backend since May so hopefully it should work better now.

from sbctl.

In case anyone found this thread just as I did - there is a possibility that if you cannot enroll your keys using sbkeysync even after using all tricks listed here (like chattr or efi-updatevar) you can try if you can enroll keys (*.auth files) within BIOS setup. It worked for me on Asus Zephyrus M16 notebook 👍

from sbctl.

i face with same issue on a framework laptop.
unfortunatelly efi-updatevar or bios is not working for me as well. is there any other way by any chance?

from sbctl.

At this point the entire codebase has moved to my own go-uefi library. Please don't forward sbkeysync issues to this tracker :)

from sbctl.