All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: Etienne Carriere <etienne.carriere@linaro.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH] [RFC] lib: efi_loader: don't delete invalid handles
Date: Thu, 8 Sep 2022 14:17:18 +0900	[thread overview]
Message-ID: <20220908051718.GA49917@laputa> (raw)
In-Reply-To: <CAPnjgZ1e-mP8AFFiXUedmEVvc-VJHY+xE-ZAedM7nJ189PP_vw@mail.gmail.com>

On Wed, Sep 07, 2022 at 03:10:44PM -0600, Simon Glass wrote:
> Hi Etienne,
> 
> On Wed, 7 Sept 2022 at 02:20, Etienne Carriere
> <etienne.carriere@linaro.org> wrote:
> >
> > Changes efi_delete_handle() to not free EFI handles that are not related
> > to EFI objects.
> >
> > This change tries to resolved an issue seen since U-Boot v2022.07
> > in which EFI ExitBootService  attempts to release some EFI handles twice.
> >
> > The issue was seen booting a EFI shell that invokes 'connect -r' and
> > then boots a Linux kernel. Execution of connect command makes EFI
> > subsystem to bind a block device for each root block devices EFI handles.
> > However these EFI device handles are already bound to a driver and we
> > can have 2 registered devices relating to the same EFI handler. On
> > ExitBootService, the loop removing the devices makes these EFI handles
> > to be released twice which corrupts memory.
> >
> > This patch prevents the memory release operation caused by the issue but
> > I don't think this patch is the right way to addresse the problem. Any
> > help will be much appreciated.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> > ---
> >  lib/efi_loader/efi_boottime.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> +AKASHI Takahiro who has been working on resolving the mismatch
> between driver model and the EFI implementation. We should be able to
> attach EFI data structures to driver model devices, which may help
> with this issue.

The only driver which supports DRIVER_BINDING_PROTOCOL, hence
connect_controller() interface, in the current UEFI implementation
is "EFI block driver" (lib/efi_driver/efi_block_device.c).

*Ordinary* block devices, other than UCLASS_EFI_LOADER, are set up
without *binding* step. Nevertheless, "connect -r" eventually
ends up calling "bind" operation of efi_block_device against those
devices.
I guess that it is the root cause.

efi_uc_supported() should have a stricter check.

-Takahiro Akashi


> What is the next step, there?
> 
> Regards,
> Simon

  reply	other threads:[~2022-09-08  5:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07  8:20 [PATCH] [RFC] lib: efi_loader: don't delete invalid handles Etienne Carriere
2022-09-07 21:10 ` Simon Glass
2022-09-08  5:17   ` AKASHI Takahiro [this message]
2022-09-08  5:56   ` Heinrich Schuchardt
2022-09-09  6:49     ` Heinrich Schuchardt
2022-09-09  8:46       ` Etienne Carriere
2022-09-08  6:03 ` Heinrich Schuchardt
2022-09-08 10:10   ` Etienne Carriere

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=20220908051718.GA49917@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=etienne.carriere@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --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 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.