rotate-keys seems to enroll keys without vendor certificates/TPM Eventlog checksums

[xlacroixx]

Bonjour,

I have a system that had Secure Boot previously set up with sbctl.

I disabled it, cleared all the keys from my UEFI setup utility (to enter Setup mode),
then first tried running create-keys. It said keys were already created, so I
ran rotate-keys instead. Running reset beforehand doesn't seem to change
the behavior.

When run, the command rotate-keys (without any flags) reports that it has
automatically enrolled new keys without enrolling any vendor certificates
(e.g. Microsoft certificates).
There is no documented flag or option to override this behavior.
I've examined the source code and it doesn't look like both commands perform
the same action, that is, enroll. But I'm not sure, I never programmed in Go before,
and especially didn't code programs that interface with low-level boot utilities.

Running list-enrolled-keys will report that there are no keys, whether
PK, KEX or Signature Database.

Running enroll-keys --microsoft does work though. It will actually enroll
the keys along with Microsoft certificates, and running list-enrolled-keys
will list all three keys along with Microsoft certificates.

At best, it could just be outdated logging. At worst, it might soft-brick machines
if the user isn't careful enough and has a problematic setup.

Merci d'avoir lu.

Version: 0.15.4.2.g237ac77
(latest commit as of posting, built from source using sbctl-git AUR package)
Also present in 0.15.3

[Foxboron]

might brick machines if the user isn't careful enough.

Nothing is going to be bricked.

When run, the command rotate-keys (without any flags) reports that it has automatically enrolled new keys without enrolling any vendor certificates (e.g. Microsoft certificates).

Right, we don't record the enrolled vendor certs before doing this so we are currently not adding them back after rotation. That should be fixed.

[Foxboron]

I looked at this again. The intention of rotate-keys is to replace an existing system keys. If you run rotate-keys without enroll-keys first then nothing will be included. However if you always run enroll-keys it will inherit the enrolled vendors certs as expected, so rotate-keys is fine.

The unexpected part is probably that rotate-keys also enrolls the keys and puts it out of setup-mode? But this is somewhat intended. So I'm not sure what the best idea would be here. I'm not going to reimplement the enroll-keys flags into rotate-keys as well. That doesn't seem very productive.

[Ten0]

Nothing is going to be bricked.

It's unclear to me why this may not brick machines considering https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom

[Foxboron]

It's unclear to me why this may not brick machines considering https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom

That page is not describing bricking.

[xlacroixx]

It does, or at the very least, it describes "soft bricking":

The effect of this, depending on the hardware, is essentially "soft bricking" the device. If you don't have any iGPU but your nvidia card has Option ROM that fails to validate, you might not have any way to display graphics. This would prevent you from turning off secure boot.

[Foxboron]

It does, or at the very least, it describes "soft bricking":

Correct. It's a poor word to describe a failure case if you don't have an internal GPU. This is no way the same as bricking anything as you can still very much solve the problem.

[xlacroixx]

Correct. It's a poor word to describe a failure case if you don't have an internal GPU. This is no way the same as bricking anything as you can still very much solve the problem.

Well yes, it's definitely recoverable if some precautions are taken.

But if one does not set up SSH beforehand and has no integrated GPU (as on most AMD Ryzen desktop processors like mine), only a discrete GPU (which will be validated by the Secure Boot chain) then some unfortunate things will happen.

So using the improper term for this issue is my bad. But at the same time I didn't want this to be too under-emphasized, since it could have affected me.

I will edit my issue so the proper term is used.

[Ten0]

Soft-bricking seems like a very appropriate term.
"You can still very much solve the issue": if the laptop is secure-boot enabled, not booting and doesn't have a display nor a motherboard bios reset jumper it does look hard to get it back to working.