summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorAristo Chen <[email protected]>2026-07-20 08:29:13 +0000
committerHeinrich Schuchardt <[email protected]>2026-07-27 18:50:28 +0200
commit7a63ea588911984ffb65893c2f31797a4bb65bf2 (patch)
tree077ed66ec2e3e5839c280bc79113f658408b6461 /include
parente85562963f1ddbdfe60ecbe8e55444743f00ade6 (diff)
cmd: nvedit_efi: use efi_auth_var_get_guid() for the default GUID
do_env_set_efi() hand rolls the mapping from well known variable names to their default vendor GUID and has already drifted from the canonical name_type[] table in efi_var_common.c: it does not know "dbr", so "env set -e dbr" operates on the variable under EFI_GLOBAL_VARIABLE_GUID instead of the image security database GUID, silently creating a variable that nothing will ever consume. Convert the variable name to UTF-16 before selecting the GUID and let efi_auth_var_get_guid() do the lookup. That function knows all authenticated variables including "dbr" and falls back to EFI_GLOBAL_VARIABLE_GUID for any other name, so behaviour is unchanged for "db", "dbx", "dbt" and non-authenticated variables. Future additions to the table now apply to the shell command automatically. Since the conversion now happens before the value parsing loop, free the UTF-16 name at the common exit label so the error path there does not leak it. Also drop the unmap_sysmem() call right after efi_set_variable_int(): the common exit path already unmaps the value for the -i case and frees it otherwise, so the value was unmapped twice. On sandbox the second call triggers a spurious "Address not mapped" warning for addresses that get a tagged mapping. Signed-off-by: Aristo Chen <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions