All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC 1/8] efi_loader: boottime: don't add device path protocol to image handle
Date: Wed, 27 Mar 2019 11:50:11 +0900	[thread overview]
Message-ID: <20190327025009.GP9937@linaro.org> (raw)
In-Reply-To: <7e84b00f-805a-f5b6-e459-d35c69d2d036@gmx.de>

On Wed, Mar 06, 2019 at 06:29:14AM +0100, Heinrich Schuchardt wrote:
> On 3/6/19 6:04 AM, Heinrich Schuchardt wrote:
> > On 3/6/19 1:27 AM, AKASHI Takahiro wrote:
> >> On Tue, Mar 05, 2019 at 08:48:37PM +0100, Heinrich Schuchardt wrote:
> >>> On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> >>>> It is just wrong to add devcie path protocol to image handle.
> >>>>
> >>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>>> ---
> >>>>  lib/efi_loader/efi_boottime.c | 11 +----------
> >>>>  1 file changed, 1 insertion(+), 10 deletions(-)
> >>>>
> >>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> >>>> index bd8b8a17ae71..7bd9c0a952d4 100644
> >>>> --- a/lib/efi_loader/efi_boottime.c
> >>>> +++ b/lib/efi_loader/efi_boottime.c
> >>>> @@ -1540,17 +1540,8 @@ efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path,
> >>>>  	info->file_path = file_path;
> >>>>  	info->system_table = &systab;
> >>>>  
> >>>> -	if (device_path) {
> >>>> +	if (device_path)
> >>>>  		info->device_handle = efi_dp_find_obj(device_path, NULL);
> >>>> -		/*
> >>>> -		 * When asking for the device path interface, return
> >>>> -		 * bootefi_device_path
> >>>> -		 */
> >>>> -		ret = efi_add_protocol(&obj->header,
> >>>> -				       &efi_guid_device_path, device_path);
> >>>
> >>> Installing the device path is not the problem. It is the GUID that is
> >>> wrong. Use EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID here.
> >>
> >> Okay, but I believe that we need duplicate device_path here
> >> before installing it as EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID.
> >>
> >> See this line:
> >>
> >>>>  		info->device_handle = efi_dp_find_obj(device_path, NULL);
> >>
> >> Normally, device_path is expected to be already associated with
> >> another handle. We should not allow two handles to share one protocol(data).
> >> That is also why I initially believed that add_protocol() should be removed.
> > 
> > The spec says we should use a copy of the unchanged DevicePath parameter
> > of LoadImage() which may be NULL.
> > 
> > So we have to rework all callers to get the device_path parameter of
> > efi_setup_loaded_image() right.
> > 
> 
> Why are we constructing a dummy memory device path at all in cmd/bootefi?
> 
> The commit message of patch bf19273e81eb "efi_loader: Add mem-mapped for
> fallback" that introduced this does not give a valid answer as it is
> explicitly allowable to call LoadImage with DevicePath = NULL if
> SourceBuffer is provided.

As far as I know, if we load EDK2's Shell.efi by calling LoadImage
*without* DevicePath, it will fail to boot at some assertion check.

-Takahiro Akashi

> So I suggest we rid ourselves of the dummy device path with this patch
> series.
> 
> Best regards
> 
> Heinrich

  reply	other threads:[~2019-03-27  2:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05  5:53 [U-Boot] [RFC 0/8] efi_loader: rework bootefi/bootmgr AKASHI Takahiro
2019-03-05  5:53 ` [U-Boot] [RFC 1/8] efi_loader: boottime: don't add device path protocol to image handle AKASHI Takahiro
2019-03-05 19:48   ` Heinrich Schuchardt
2019-03-06  0:27     ` AKASHI Takahiro
2019-03-06  5:04       ` Heinrich Schuchardt
2019-03-06  5:29         ` Heinrich Schuchardt
2019-03-27  2:50           ` AKASHI Takahiro [this message]
2019-03-05  5:53 ` [U-Boot] [RFC 2/8] efi_loader: boottime: export efi_[un]load_image() AKASHI Takahiro
2019-03-05 20:02   ` Heinrich Schuchardt
2019-03-05  5:53 ` [U-Boot] [RFC 3/8] efi_loader: bootmgr: return pointer and size of buffer in loading AKASHI Takahiro
2019-03-21 11:41   ` Heinrich Schuchardt
2019-03-22  2:08     ` AKASHI Takahiro
2019-03-05  5:53 ` [U-Boot] [RFC 4/8] cmd: bootefi: move do_bootefi_bootmgr_exec() forward AKASHI Takahiro
2019-03-21 11:48   ` Heinrich Schuchardt
2019-03-22  2:16     ` AKASHI Takahiro
2019-03-05  5:53 ` [U-Boot] [RFC 5/8] cmd: bootefi: carve out fdt handling AKASHI Takahiro
2019-03-05  5:53 ` [U-Boot] [RFC 6/8] cmd: bootefi: carve out efi_selftest code from do_bootefi() AKASHI Takahiro
2019-03-05  5:53 ` [U-Boot] [RFC 7/8] cmd: bootefi: rework do_bootefi(), using load_image API AKASHI Takahiro
2019-03-05  5:53 ` [U-Boot] [RFC 8/8] cmd: add efibootmgr command AKASHI Takahiro
2019-03-19  7:23 ` [U-Boot] [RFC 0/8] efi_loader: rework bootefi/bootmgr AKASHI Takahiro
2019-03-21  6:41   ` Heinrich Schuchardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190327025009.GP9937@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.