Bug 1213859

Summary:	fdectl should mention Secure Boot state in errors
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	JuPing Chan <email>
Component:	Bootloader	Assignee:	Bootloader Maintainers <bootloader-maintainers>
Status:	NEW ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	glin
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description JuPing Chan 2023-08-01 10:25:38 UTC

Following the exciting announcement by Gary Lin on the mailing list on disk auto-unlocking with TPM 2.0, I have spent half a day testing it out on my home server (Topton NAS N1 Pro) setup. It was a full reinstall of Tumbleweed with Secure Boot enabled.

I encountered one stumbling block which took me awhile to fix because I am unfamiliar with Secure Boot setups.

I ran `sudo fdectl regenerate-key` and `sudo fdectl tpm-authorize` which threw the same error for three different key hashes:

>Error: Unable to read EFI variable "<hash>"

Confused, I checked in YaST that I had enabled Secure Boot. It was enabled, but it was somehow not active.

I then ran `mokutil --sb-state` which told me:

>SecureBoot disabled
>Platform is in Setup Mode

Which finally gave me enough clues to figure out that my home server was in setup mode for Secure Boot despite already being enabled, and wasn't active, in UEFI. Quite confusingly still, all the options to reset the platform keys were greyed out.

I figured out how to load the factory options by changing Secure Boot Mode from Standard to Custom, then I was able to reset the keys.

In summary, I think apart from the error generated from fdectl, perhaps an error output from mokutil can also be added?

Comment 1 Gary Ching-Pang Lin 2023-08-02 02:59:09 UTC

You probably saw the error messages like this:

Error: Unable to read EFI variable "PK-8be4df61-93ca-11d2-aa0d-00e098032b8c"
Error: Unable to read EFI variable "KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c"
Error: Unable to read EFI variable "db-d719b2cb-3d3a-4596-a3bc-dad00e67656f"

It's from pcr-oracle which tries to traverse the TPM event log and predict the PCR values. For the system in setup mode, those Secure Boot variables would be mentioned in the event log but not available in runtime since those variables are empty. Anyway, pcr-oracle just complains the error and continues the calculation of PCR values.

Maybe I should add the mokutil check in the beginning to remind the user to enable Secure Boot correctly.

Comment 2 JuPing Chan 2023-08-02 03:07:37 UTC

Yep! Those are the errors I saw.

For Secure Boot, it was a surprising discovery as well to see that Secure Boot was in a setup state in UEFI, because the server initially came with Windows 11 and I made some assumptions.

Does that mean automated key enrolment is a potential feature too if fdectl detects this state in the UEFI?

I will get better knowing the material eventually thanks to making this feature easily accessible!

Comment 3 Gary Ching-Pang Lin 2023-08-02 08:57:38 UTC

(In reply to JuPing Chan from comment #2)
> Yep! Those are the errors I saw.
> 
> For Secure Boot, it was a surprising discovery as well to see that Secure
> Boot was in a setup state in UEFI, because the server initially came with
> Windows 11 and I made some assumptions.
> 
Indeed, I assume Windows 11 would request Secure Boot to be enabled, but it seems not.

> Does that mean automated key enrolment is a potential feature too if fdectl
> detects this state in the UEFI?
> 
Probably no. We have no plan to enroll any key into UEFI db, at least for now.

> I will get better knowing the material eventually thanks to making this
> feature easily accessible!

No problem. It's nice to receive some feedback for fde-tools :)