"env set -e" selects a default vendor GUID when no -guid option is given, using a hand rolled name check in do_env_set_efi(). That check has drifted from the canonical name_type[] table in lib/efi_loader/efi_var_common.c: it knows db, dbx and dbt but not dbr, so "env set -e dbr" silently operates on a variable under EFI_GLOBAL_VARIABLE_GUID instead of the image security database GUID, creating a variable that no consumer will ever look up. The command also unmapped the -i value buffer twice, which triggers a spurious "Address not mapped" warning on sandbox for addresses that get a tagged mapping.
Patch 1 replaces the hand rolled check with a call to efi_auth_var_get_guid() so that the shell command and the variable service share a single table, and consolidates the value and name cleanup on the common exit path. Behaviour is unchanged for db, dbx, dbt and for non-authenticated variable names. Patch 2 adds a test case to the sandbox secure boot suite that enrolls each of db, dbx, dbt and dbr in setup mode without an explicit -guid option and checks that every variable is created under the image security database GUID and not under the global variable GUID. This is the first coverage of dbt and dbr under test/. The enrollment happens in setup mode because once secure boot is enabled, efi_variable_authenticate() only accepts writes to PK, KEK, db and dbx. The new test fails at the dbr step without patch 1. Aristo Chen (2): cmd: nvedit_efi: use efi_auth_var_get_guid() for the default GUID test: check default GUID selection of signature database variables cmd/nvedit_efi.c | 22 +++++--------- test/py/tests/test_efi_secboot/conftest.py | 8 +++++ .../py/tests/test_efi_secboot/test_authvar.py | 30 +++++++++++++++++++ 3 files changed, 46 insertions(+), 14 deletions(-) -- 2.43.0
