All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH 1/1] efi_loader: fix efi_initrd_deregister()
Date: Fri, 30 Sep 2022 15:41:42 +0900	[thread overview]
Message-ID: <20220930064142.GA17468@laputa> (raw)
In-Reply-To: <CAC_iWj+47cSUXxKuNJajfiF6Dv0e6Au=vpEdYNuBXrTmxhQPUQ@mail.gmail.com>

Ilias,

On Fri, Sep 30, 2022 at 09:18:35AM +0300, Ilias Apalodimas wrote:
> Akashi-san
> 
> On Fri, 30 Sept 2022 at 04:47, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > On Fri, Sep 30, 2022 at 01:57:48AM +0200, Heinrich Schuchardt wrote:
> > > Don't try to delete a non-existent handle.
> >
> > It is okay as a safe guard, but it doesn't fix underlying issues.
> 
> I dont think we safeguard anything. That code path won't try to delete
> anything regardless?
> 
> >
> > efi_initrd_register() is called only in efi_bootmgr_load(), and so
> > efi_initrd_deregister() should be called only at the paired location.
> 
> There's a reason for that.
> >
> > - Remove efi_initrd_deregister() from do_bootefi_exec()
> > - do_efibootmgr() should look like
> >       efi_bootmgr_load()
> >       do_bootefi_exec()
> >       efi_initrd_deregister()
> > Otherwise, do_bootefi_exec() always tries to free a handle in
> > the other cases (i.e. bootefi <addr>).
> >
> > Another issue is there in try_load_entry() called by efi_bootmgr_load().
> >      (after efi_initrd_register())
> >      if (size) {
> >                 *load_options = malloc(size);
> >                 if (!*load_options) {
> >                         ret = EFI_OUT_OF_RESOURCES;
> >                         goto error;
> >                 }
> >                 ...
> >
> > If malloc() fails, we should call efi_initrd_deregister() within
> > try_load_entry().
> >
> > Should I submit a patch?
> 
> The whole implementation on the *kernel* assumes the protocol is
> present if the file it's pointing is real and existing.  You also need
> to have a single instance of the protocol installed.  IOW if you
> install the protocol and the initrd is not there, the kernel won't
> fallback on the dt /chosen/ node or the initrd= in the cmdline.

Yes, I confirmed that before I made my comment.

> The
> whole initrd loading logic depends on BootCurrnent, which iirc is not
> set yet on the flow you are proposing.

I don't get your point.

In do_efibootmgr(), what I suggested above is:
- efi_bootmgr_load() installs LOAD_FILE2_PROTOCOL if initrd file exists,
  and if this function fails, LOAD_FILE2_PROTOCOL must be uninstalled any way.
- after returning from UEFI app invoked by do_bootefi_exec(),
- we should simply uninstall LOAD_FILE2_RPTOCOL by calling efi_initrd_deregister().

In "bootefi <addr>" case, efi_bootmgr_load() is not called, so
LOAD_FILE2_PROTOCOL won't be installed for loading initrd file.
Why do we have to call efi_initrd_deregister() in that case?

Regarding BootCurrent, I don't think it has nothing to do with the discussion above.
Anyhow it *is* set before reaching "if (size) ...".

-Takahiro Akashi


> Regards
> /Ilias
> >
> > -Takahiro Akashi
> >
> > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > ---
> > >  lib/efi_loader/efi_load_initrd.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/lib/efi_loader/efi_load_initrd.c b/lib/efi_loader/efi_load_initrd.c
> > > index c5e6652e66..3d6044f760 100644
> > > --- a/lib/efi_loader/efi_load_initrd.c
> > > +++ b/lib/efi_loader/efi_load_initrd.c
> > > @@ -230,6 +230,9 @@ efi_status_t efi_initrd_register(void)
> > >   */
> > >  void efi_initrd_deregister(void)
> > >  {
> > > +     if (!efi_initrd_handle)
> > > +             return;
> > > +
> > >       efi_delete_handle(efi_initrd_handle);
> > >       efi_initrd_handle = NULL;
> > >  }
> > > --
> > > 2.37.2
> > >

  reply	other threads:[~2022-09-30  6:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 23:57 [PATCH 1/1] efi_loader: fix efi_initrd_deregister() Heinrich Schuchardt
2022-09-30  1:47 ` AKASHI Takahiro
2022-09-30  6:18   ` Ilias Apalodimas
2022-09-30  6:41     ` AKASHI Takahiro [this message]
2022-09-30  6:54       ` Ilias Apalodimas
2022-09-30  7:18         ` Heinrich Schuchardt
2022-09-30  7:29           ` Ilias Apalodimas
2022-09-30  7:55             ` Heinrich Schuchardt
2022-09-30  7:59               ` Ilias Apalodimas
2022-09-30  6:15 ` Ilias Apalodimas

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=20220930064142.GA17468@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=ilias.apalodimas@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.