Update EFI load option UUID #415
Conversation
It's now 2024. Pytest is superior to unittest and has been available in Debian since at least buster. Just use it. While here, invoke it as a module to avoid whatever Debian is naming the CLI entrypoint these days. https://phabricator.endlessm.com/T31604
This is from an Endless VM using TianoCore with Secure Boot enabled (and throwaway keys in the databases). A pytest fixture is provided to make testing with the data safer.
When the partition UUID for the ESP is updated, any load options referencing the partition become invalid. Add a tool to update all load options using the old partition UUID to the new partition UUID. This uses the libefivar and libefiboot packages to access EFI variables and interpret the data appropriately. https://phabricator.endlessm.com/T31604
When the ESP partition ID is regenerated, any EFI load options referencing the old partition ID become invalid. While shim's fallback will generate a new load option on the next boot, a downstream patch is needed to make sure the invalid option is removed. Rather than having shim cleanup this situation, update the load options at the time the partition UUID is changed. Since both the old and new UUIDs are known, eos-update-efi-uuid can update only the affected load options without changing or deleting load options that aren't affected by the UUID change. Note that this runs eos-update-efi-uuid in verbose mode, which is pretty noisy. When we have confidence this is doing the right thing, we can drop the -v option. https://phabricator.endlessm.com/T31604
There was a problem hiding this comment.
Very nifty. I didn't review this as thoroughly as I would have liked but it looks solid. I'll take another look tomorrow if @starnight doesn't beat me to it!
| @@ -2,8 +2,4 @@ | |||
| set -e | |||
|
|
|||
| cd "$(dirname "$0")" | |||
| if pytest=$(which py.test-3); then | |||
There was a problem hiding this comment.
Great. I have a distant memory of adding this and making it conditional because, at the time, we maintained the whole distro rather than just a layer atop Debian.
| @@ -0,0 +1,2 @@ | |||
| # Define hexdump textconv with "git config diff.efivars.textconv hd" | |||
| tests/efivars/* diff=efivars | |||
There was a problem hiding this comment.
+++ b/tests/efivars/PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
@@ -0,0 +1,3 @@
+00000000 06 00 00 00 65 6e 3b 66 72 3b 65 6e 2d 55 53 3b |....en;fr;en-US;|
+00000010 66 72 2d 46 52 00 |fr-FR.|
+00000016
Interesting, I wonder where French came from?
There was a problem hiding this comment.
🤷 This comes from TianoCore (EDK2), so my guess is someone bothered to do French translations for it. Yeah, now I see some translations.
| free (p); | ||
| } | ||
|
|
||
| #define cleanup_free __attribute__ ((cleanup (_cleanup_free))) |
There was a problem hiding this comment.
The cleanup attribute is magic to me! :)
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute
This is my first time see how does it implemented!
During first boot the ESP partition UUID is changed so that it's unique from the UUID in the image. Unfortunately, this invalidates the EFI load option just created by shim's fallback. Until now the way this has been managed has been to let fallback create a new EFI load option matching the new UUID on the second boot. That works OK, but it's kind of ugly and it requires a downstream fallback patch to ensure the invalid EFI load option is cleaned up.
Rather than leave the invalid EFI load option for shim and fallback to deal with, update it with the new ESP UUID. Make this update from the dracut repartition module since this is the only time we definitively know the old and new ESP UUIDs. A new tool,
eos-update-efi-uuid, is added to handle updating the boot option. It useslibefivarandlibefibootto inspect and update the existing load options.https://phabricator.endlessm.com/T31604