linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: ard.biesheuvel@arm.com, Ard Biesheuvel <ardb@kernel.org>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Ingo Molnar <mingo@kernel.org>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] efi/libstub: Allow EFI_NOT_FOUND on LOAD_FILE2_PROTOCOL calls for initrd
Date: Mon, 14 Dec 2020 19:48:40 +0200	[thread overview]
Message-ID: <X9eleMqn6Ron/myG@apalos.home> (raw)
In-Reply-To: <aa66cc54-f987-cdcd-05a7-4b63aa8b422d@gmx.de>

On Mon, Dec 14, 2020 at 06:39:21PM +0100, Heinrich Schuchardt wrote:
> On 14.12.20 18:01, Ilias Apalodimas wrote:
> > At the moment the EFI stub tries to load an initrd from the
> > cmdline provided option only if the LoadFile2 protocol does not exist
> > on the initrd device path.
> >
> > This might prove problematic for EFI installers that need their own
> > version of initrd to start the installation process and the firmware
> 
> Did you hit a real world case?
> 

Yes while trying to install debian with U-boot, in which I enabled LoadFile2
protocol

[...]
> > @@ -599,7 +600,14 @@ efi_status_t efi_load_initrd_dev_path(unsigned long *load_addr,
> >  				(void *)initrd_addr);
> >  	if (status != EFI_SUCCESS) {
> >  		efi_free(initrd_size, initrd_addr);
> > -		return EFI_LOAD_ERROR;
> > +		/*
> > +		 * Some firmware implementations might install the EFI
> 
> In U-Boot the filename is set a compile time. As the path may relate to
> a removable medium, it would not make sense to check the existence of
> the file when installing the protocol.
> 

Agree. That's why I am trying to change the behavior of the stub slightly
and respect the firmware's return value on this.
More over the whole idea is to load the file exactly when requested, rather
than store it in memory and wait until someone requests it.

> > +		 * protocol without checking the file is present and return
> > +		 * EFI_NOT_FOUND when trying to load the file.
> > +		 * If that's the case, allow the cmdline defined initrd to
> > +		 * load.
> 
> U-Boot's implementation could also return EFI_NO_MEDIA if
> CONFIG_EFI_INITRD_FILESPEC relates to a non-existent partition.
> 
> Why should we fall back to the command line in this case?
> 
> The whole idea of this protocol is to disallow the specification of an
> initrd via the command line.

We are not falling back in that case. We only allow a fallback if 
EFI_NOT_FOUND is explicitly returned. 

That being said my check is wrong. I need to check it on the first invocation
of load file, not the last one. I'll send a V2

Regards
/Ilias

      reply	other threads:[~2020-12-14 17:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 17:01 [PATCH] efi/libstub: Allow EFI_NOT_FOUND on LOAD_FILE2_PROTOCOL calls for initrd Ilias Apalodimas
2020-12-14 17:39 ` Heinrich Schuchardt
2020-12-14 17:48   ` Ilias Apalodimas [this message]

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=X9eleMqn6Ron/myG@apalos.home \
    --to=ilias.apalodimas@linaro.org \
    --cc=ard.biesheuvel@arm.com \
    --cc=ardb@kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=xypron.glpk@gmx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).