Hi Ilias,
On 2023-07-28 14:15 +03:00, Ilias Apalodimas wrote: > On Sat, 8 Jul 2023 at 18:21, Alper Nebi Yasak <alpernebiya...@gmail.com> > wrote: >> >> Debian's arm64 UEFI Secure Boot shim makes the EFI variable store run >> out of space while mirroring its MOK database to variables. This can be >> observed in QEMU like so: >> >> $ tools/buildman/buildman -o build/qemu_arm64 --boards=qemu_arm64 -w >> $ cd build/qemu_arm64 >> $ curl -L -o debian.iso \ >> >> https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.0.0-arm64-netinst.iso >> $ qemu-system-aarch64 \ >> -nographic -bios u-boot.bin \ >> -machine virt -cpu cortex-a53 -m 1G -smp 2 \ >> -drive >> if=virtio,file=debian.iso,index=0,format=raw,readonly=on,media=cdrom >> [...] >> => # interrupt autoboot >> => env set -e -bs -nv -rt -guid 605dab50-e046-4300-abb6-3dd810dd8b23 >> SHIM_VERBOSE 1 >> => boot >> [...] >> mok.c:296:mirror_one_esl() SetVariable("MokListXRT43", ... varsz=0x4C) = >> Out of Resources >> mok.c:452:mirror_mok_db() esd:0x7DB92D20 adj:0x30 >> Failed to set MokListXRT: Out of Resources >> mok.c:767:mirror_one_mok_variable() mirror_mok_db("MokListXRT", >> datasz=17328) returned Out of Resources >> mok.c:812:mirror_one_mok_variable() returning Out of Resources >> Could not create MokListXRT: Out of Resources >> [...] >> Welcome to GRUB! >> >> This would normally be fine as shim would continue to run grubaa64.efi, >> but shim's error handling code for this case has a bug [1] that causes a >> synchronous abort on at least chromebook_kevin (but apparently not on >> QEMU arm64). >> >> Double the default variable store size so the variables fit. There is a >> note about this value matching PcdFlashNvStorageVariableSize when >> EFI_MM_COMM_TEE is enabled, so keep the old default in that case. > > Thanks for the report. That EFI_MM_COMM_TEE basically means that the > variables will be stored in an RPMB partition of an eMMC device. This > has a couple of advantages compared to storing it in a file (mostly > security related), but I can change that in the future. I've read your article on it, but haven't really explored this stuff because one-time-programmable things make me a bit afraid. Mind that this happens even without any persistence at all, i.e. ENV_IS_NOWHERE and EFI_VARIABLE_NO_STORE. > When you use 32kb how much space do you have left after MoK etc have > been written? I can press "c" at the GRUB menu and run "exit" to get back to the U-Boot shell, then I have: => efidebug query -bs -rt -nv Max storage size 65512 Remaining storage size 54968 Max variable size 65480 => env print -e -n SecureBoot: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x1 SetupMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x1 AuditMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x1 DeployedMode: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x1 VendorKeys: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x1 PlatformLangCodes: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x6 PlatformLang: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) NV|BS|RT, DataSize = 0x6 OsIndicationsSupported: 8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID) BS|RT|RO, DataSize = 0x8 SbatLevel: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) NV|BS, DataSize = 0x19 MokListRT: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) BS|RT, DataSize = 0x3ce MokListXRT: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) BS|RT, DataSize = 0x21d8 SbatLevelRT: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) BS|RT, DataSize = 0x19 MokListTrustedRT: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) BS|RT, DataSize = 0x1 It's weird seeing 65512 - 54968 == 10544 < 16K. (Heinrich bumped it to 64K as he applied the patch, based on Windows docs.) But I'm noticing how MokListXRT DataSize 0x21d8 * 2 == 17328 matches the datasz value in the error. If I retry with 16K, I see 43 extra values each with 0x4c size in addition to the above. => efidebug query -bs -rt -nv Max storage size 16360 Remaining storage size 0 Max variable size 16328 => env print -e -n [...] MokListXRT1: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) BS|RT, DataSize = 0x4c [..] MokListXRT43: 605dab50-e046-4300-abb6-3dd810dd8b23 (605dab50-e046-4300-abb6-3dd810dd8b23) BS|RT, DataSize = 0x4c Hope that helps, tell me if there's other commands you want me to run.
