On Wed, Feb 27, 2019 at 07:39:50AM +0100, Heinrich Schuchardt wrote: > On 2/27/19 7:27 AM, AKASHI Takahiro wrote: > > On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote: > >> 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.aka...@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. > > > > So is your answer yes, or no? > > I would prefer calling efi_get_variable() directly and not to use > rs->get_variable().
My point is "including get_var()" or not. I have never touched that function in my patch. > > > >> 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 > > > > I'm not sure about your concern here, but no doubt efidebug should > > be disabled on production system with secure boot. > > Also in efidebug we are creating more runtime code bytes than needed by > using system->runtime->efi_something() or system->boottime->efi_something(). I think we discussed in the past. I prefer to calling boot time/run time services via system table as this command is expected to be implemented as an (embedded) EFI application sometime in the future. Thanks, -Takahiro Akashi > Best regards > > Heinrich > > > > > Thanks, > > -Takahiro Akashi > > > >> 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; > >>>>> > >>>> > >>> > >> > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot