Better UEFI Secure Boot handling

[miczyg1]

The problem you're addressing (if any)
Currently Dasharo always enrolls a set of default SB keys and enables SB by default. Also the key management in the setup does not seem to be working that well.

Describe the solution you'd like
Rebase to a newer Secure Boot driver from EDK2 which has better support for managing default keys. Also the SB should be disabled by default.

Where is the value to a user, and who might that user be?
Some GPU OptionROMs had problems with Secure Boot, OptionROMs were refused to boot. Better Secure Boot handling should benefit from better experience overall.

Describe alternatives you've considered
None

Additional context
None

[macpijan]

The patches @miczyg1 has mentioned were posted here: https://www.mail-archive.com/devel@edk2.groups.io/msg33328.html

They introduce additional features, such as:

• ability to embedded one's default Secure Boot keys in a firmware binary,
• new menu entry which allows to reset Secure Boot keys to default.

These changes were discussed here: https://edk2.groups.io/g/rfc/topic/82139806# with some nice design proposal here: https://drive.google.com/file/d/11yNJJ2x8WXYZRg1nZWrr4C4Hq89Izn1D/view

These are part of the upstream edk2 since August 2021. So to have them in Dasharo, we probably need to rebase our fork.

[pietrushnic]

Dashro/edk2 rebase is IMHO very important, question is how much work it is. Also I'm not sure if we have regression testing for our features. Our fork is very old and we should start applying to EDKII the same policy as we have for coreboot.

[macpijan]

It seems it is our latest common commit with tianocore/edk2 upstream:

commit dd7523b5b123de6f0730f2f2abb207f2a5c1ccd4
Author: Sami Mujawar <sami.mujawar@arm.com>
Date:   Mon Nov 18 16:37:30 2019 +0000

This was probably a base of 9e fork.

A next commit in history is:

commit 416768c16b1869302eed60e2d53b5279c246186d
Author: Patrick Rudolph <patrick.rudolph@9elements.com>
Date:   Mon May 11 14:43:47 2020 +0200

[pietrushnic]

We need approach in which we can stay on top of all most important forks. I guess most of the stuff that coreboot community develops land in MrChromebox fork. Maybe that one is best to follow and meanwhile upstream what we have to Tianocore. Also we should start identify upstream problems and create issues in edk2 bugzilla e.g. there were some issues in RTC area which caused problems on PC Engines apuX. I'm pretty sure it is part of our fork, question if it is fixed upstream.

[macpijan]

When comparing our fork with current 9e or mrchromebox, or corboot (the one from gerrit) forks, the most recent commit is the one as from the upstream.

So we carry a list of 164 commits on top of the old upstream version from 2019: https://paste.dasharo.com/?612c291c03162f9c#FSb6NMiEjdKaJUEtvrvE1h6CEoFrJpzipeFfBWwNby8L

Around half of it is from 9e, but they do not exist on their recent branches anymore.

[pietrushnic]

One have to figure out if that was rebased or upstreamed, or maybe no longer needed for other reasons.

[macpijan]

We may need to start with cleaning up of our banch.
I have reduced the number of patches from 93 to 57 here: https://github.com/Dasharo/edk2/commits/dasharo-cleanup

Some notes of the cleanup: https://paste.dasharo.com/?4918a3305168c827#6pLq4zpkFjsURQdAyBEbNm2u8q53RHR1vw4oYbmxz34R (oldest commits on the bottom).

[macpijan]

I have looked (very briefly) on the out-of-tree commits on our branch. Ay least most of them look like already picked in https://github.com/MrChromebox/edk2/commits/uefipayload_202207 or addressed in other way.
I think we should try to apply just our changes on top of this branch.

[miczyg1]

Applied some fixes on what @macpijan prepared here: Dasharo/edk2#29
and now it works. It is possible to load default keys with the new menu option. Sanity checks made:

1. By default on first boot no keys/certificates are enrolled, so it is not possible to enable Secure Boot in the menu. PASS
2. Selecting Reset Secure Boot Keys loads the keys from default variables, populated from certs included in the UEFI Payload. Secure Boot gets automatically enabled, as all SB variables are in place. PASS
3. Secure Boot can be disabled after enrolling default keys. PASS.
4. Windows installer is booting with Secure Boot enabled. PASS
5. Ubuntu 22.04 preinstalled is booting with Secure Boot enabled (using shimx64.efi). PASS
6. Ubuntu 22.04 preinstalled is NOT booting with Secure Boot enabled (using grubx64.efi). PASS
7. Everything else boots with Secure Boot disabled. PASS

[pietrushnic]

@sulewskiprzemyslaw in long run all those tests should be implemented and tested as part of Dasharo Certification Program to avoid regression.

[pietrushnic]

@miczyg1 I guess 5 and 6 contradict each other

[miczyg1]

@miczyg1 I guess 5 and 6 contradict each other

No? shimx64.efi is the Microsoft signed shim loader which chainloads grubx64.efi which boots OS.
grubx64.efi is not Microsoft signed and booting it directly will return Access Denied because of Secure Boot enabled.

[rafkoch]

@miczyg1 @pietrushnic @macpijan

1. The goal of this issue was "Some GPU OptionROMs had problems with Secure Boot, OptionROMs were refused to boot. Better Secure Boot handling should benefit from better experience overall.".
2. Suggested solution was "Rebase to a newer Secure Boot driver from EDK2 which has better support for managing default keys. Also the SB should be disabled by default."
3. @sulewskiprzemyslaw did You implement or put to backlog those tests link?

I'm just trying to know if this issue is DONE (ready to move to CLOSED status)?

[sulewskiprzemyslaw]

@rafkoch current list of the Secure Boot test cases you could find in the following documentation: https://docs.dasharo.com/unified-test-documentation/dasharo-security/206-secure-boot/.

The tests from the scope described by @miczyg1 haven't been added to the backlog.

[miczyg1]

UEFI Secure Boot handling is better now indeed, but still not perfect.

Also there are problems reported that MOK keys could not be enrolled when using Ventoy, but this might be a different problem.

[rafkoch]

1. @miczyg1 each solution can be continuously improved because is not perfect.
   This should not prevent us from closing this task since we have provided a solution.
   If there is a need to analyze and/or improve the solution in one of the next releases, please add it to the backlog as a separate issue.
2. @sulewskiprzemyslaw I'm waiting for link to new issue added in backlog. (please do it, see point 3 of this comment).

[pietrushnic]

@miczyg1 @rafkoch we have to split this issues for the things done and not done.

More to that there are couple issues mixed here e.g. rebase to newer EDKII. @miczyg1 only you can precisely explain expectations here and mark those which are committed and which have to be developed, since you submitted this problem.

[rafkoch]

so, next steps:

1. @miczyg1 will prepare new task or tasks to backlog and will link it here.
2. @sulewskiprzemyslaw will add task to backlog (see point 3 of this [comment])(Better UEFI Secure Boot handling #119 (comment))
3. @miczyg1 will close this task.
4. I will move this task to DONE column in project.

[sulewskiprzemyslaw]

@rafkoch I just added link to the tests to Dasharo's backlog

[miczyg1]

The initial scope of this task/feature request has been done, so IMO can be closed. What can we do next?

1. Add option to erase all keys (currently one has to enter custom mode and loop through all keys and delete one by one manually)
2. Fix the MOK key enrollment in shim when using Ventoy

[rafkoch]

@miczyg1 so put this 2 ideas to the backlog and give link's to them please. (it will be step 1 frot this list)
Then move to step 3.

@sulewskiprzemyslaw so I'm waiting for link to new issue added to backlog. Thx.

[miczyg1]

1. Option to erase all Secure Boot keys #279
2. MOK key enrollment in shim doesn't work when using Ventoy #280