diff options
| author | Aristo Chen <[email protected]> | 2026-07-20 08:29:13 +0000 |
|---|---|---|
| committer | Heinrich Schuchardt <[email protected]> | 2026-07-27 18:50:28 +0200 |
| commit | 7a63ea588911984ffb65893c2f31797a4bb65bf2 (patch) | |
| tree | 077ed66ec2e3e5839c280bc79113f658408b6461 /include | |
| parent | e85562963f1ddbdfe60ecbe8e55444743f00ade6 (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
