
On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
See UEFI v2.7, section 3.1.2 for details of the specification.
With my efitool command, you can try as the following: => efi boot add 1 SHELL ... => efi boot add 2 HELLO ... => efi boot order 1 2 => efi bootmgr (starting SHELL ...) => efi boot next 2 => efi bootmgr (starting HELLO ...) => efi dumpvar <snip ...> BootCurrent: {boot,run}(blob) 00000000: 02 00 .. BootOrder: {boot,run}(blob) 00000000: 01 00 02 00 ....
Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
lib/efi_loader/efi_bootmgr.c | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c index a095df3f540b..6c5303736dc6 100644 --- a/lib/efi_loader/efi_bootmgr.c +++ b/lib/efi_loader/efi_bootmgr.c @@ -145,11 +145,21 @@ static void *try_load_entry(uint16_t n, struct efi_device_path **device_path, efi_deserialize_load_option(&lo, load_option);
if (lo.attributes & LOAD_OPTION_ACTIVE) {
u32 attributes;
efi_status_t ret;
debug("%s: trying to load "%ls" from %pD\n", __func__, lo.label, lo.file_path);
attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS;
size = sizeof(n);
ret = rs->set_variable(L"BootCurrent",
(efi_guid_t *)&efi_global_variable_guid,
Use EFI_CALL().
Okay But as I said somewhere else, it's quite annoying to me that some efi_xxx requires EFI_CALL(), and others not. There should have been consistent naming rules.
We started with having separate functions like efi_allocate_pages_ext() and efi_allocate_pages(). Then Rob Clark came along and introduced EFI_CALL() in a095aadffa96 and I stopped creating _ext() functions.
When running with DEBUG 1 it sometimes is helpful to see which function is calling which other and where errors are originally reported.
But I am open to changes in this area.
Instead of dereferencing you could directly call efi_set_variable().
Yeah, given that this code is under lib/efi_loader, it may be natural to use efi_set_variable(). But existing get_var() uses the same style of coding.
Do you want to change all of the call sites including get_var()?
Calling efi_set_variable() directly uses less bytes of code than rs->get_variable() which makes it preferable.
I have seen that iPXE modifies system->boottime to intercept system calls. The same could be done by an EFI driver to the runtime vectors.
In the light of your work on secure boot I think we should not allow an EFI driver to intercept the reading and changing of variables here.
We should also rethink it for efidebug.c
Best regards
Heinrich
attributes, size, &n);
if (ret != EFI_SUCCESS)
goto error;
ret = efi_load_image_from_path(lo.file_path, &image);
if (ret != EFI_SUCCESS)
@@ -173,16 +183,38 @@ error: void *efi_bootmgr_load(struct efi_device_path **device_path, struct efi_device_path **file_path) {
- uint16_t *bootorder;
u16 bootnext, *bootorder; efi_uintn_t size; void *image = NULL; int i, num;
efi_status_t ret;
__efi_entry_check();
bs = systab.boottime; rs = systab.runtime;
/* get BootNext */
size = sizeof(bootnext);
ret = rs->get_variable(L"BootNext",
(efi_guid_t *)&efi_global_variable_guid,
NULL, &size, &bootnext);
You could call efi_get_variable() directly instead of dereferencing rs. But anyway you have to use EFI_CALL().
Ditto
- if (!bootnext)
goto run_list;
Goto is acceptable for error handling. But otherwise I would rather avoid it.
Okay with another indentation.
- /* delete BootNext */
- ret = rs->set_variable(L"BootNext",
(efi_guid_t *)&efi_global_variable_guid,
0, 0, &bootnext);
EFI_CALL().
Thanks, -Takahiro Akashi
Best regards
Heinrich
- if (ret != EFI_SUCCESS)
goto error;
- image = try_load_entry(bootnext, device_path, file_path);
- if (image)
goto error;
+run_list:
- /* BootOrder */ bootorder = get_var(L"BootOrder", &efi_global_variable_guid, &size); if (!bootorder) goto error;