All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Cc: "Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Kazuhiko Sakamoto" <sakamoto.kazuhiko@socionext.com>,
	"Alexander Graf" <agraf@csgraf.de>,
	"Jesper Schmitz Mouridsen" <jesper@schmitz.computer>,
	"Simon Glass" <sjg@chromium.org>,
	"U-Boot Mailing List" <u-boot@lists.denx.de>,
	"Vincent Stehlé" <vincent.stehle@arm.com>,
	"Grant Likely" <grant.likely@arm.com>
Subject: Re: [PATCH] efi: Restrict the simple file system protocol to support only FAT
Date: Thu, 3 Jun 2021 09:47:11 +0300	[thread overview]
Message-ID: <YLh670FCA67myCut@Iliass-MBP> (raw)
In-Reply-To: <CAA93ih1wSw6+SJHzW8hhAFNmqgoFa4ZL33UHw-hEyHeWzF=c-Q@mail.gmail.com>

On Thu, Jun 03, 2021 at 03:36:38PM +0900, Masami Hiramatsu wrote:
> Hi Ilias,
> 
> 2021年6月3日(木) 15:25 Ilias Apalodimas <ilias.apalodimas@linaro.org>:
> >
> > [...]
> > > >
> > > > At least Debian and Ubuntu do not allow /boot to be on a FAT file system. If we want to boot Linux via the EFI stub without GRUB, we need ext4 support exposed to the EFI sub-system. See Ilias' recent contributions for the EFI_LOAD_FILE2_PROTOCOL for initrd and efidebug. This came in handy for booting via EFI on RISC-V where the initrd= command line parameter is not supported by Linux.
> > >
> > > IMHO, such dependency is out of UEFI spec. That means Debian/Ubuntu
> > > doesn't follow the UEFI spec. (but as far as I know, those install ESP
> > > on the disk and install GRUB efi application for boot)
> > > And yes, EFI_LOAD_FILE2_PROTOCOL needs to load initrd from somewhere
> > > (I'm usually put it on the ESP). But, if the EFI_LOAD_FILE2_PROTOCOL
> > > *requires* to access ext4 partition, I think that is not supported by
> > > UEFI spec.
> >
> > One of the advantages in using EFI_LOAD_FILE2_PROTOCOL is that you can load
> > it from *any* file system the firmware has access to. The only thing the
> > kernel does is provide a buffer big enough to fit in the initrd.  The
> > firmware is free to locate the file and copy it in that memory however it
> > sees fit.
> 
> Ah, I got it. Yes, EFI_LOAD_FILE2_PROTOCOL doesn't depend on the
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. Thus it should be able to load
> the file from where the U-Boot can access. However, since current implementation
> depends on the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, my patch limits
> the ability...
> 

Yea that changed recently. On the first version, I was using u-boot
internal functions to locate and load the file.  When we decided to store a
device path on Boot#### options, in order to locate the initrd, we started
using the EFI APIs to load it. You can check commit 53f6a5aa8626 for more
details.

Cheers
/Ilias
> Thank you,
> 
> >
> > Cheers
> > /Ilias
> > >
> > > Anyway, I agree that denying access to non-FAT partitions is too
> > > restricted. What about my other ideas? If the volume is set to
> > > ReadOnly, that is good for both of the SCT and the
> > > EFI_LOAD_FILE2_PROTOCOL.
> > >
> > >
> > > Thank you,
> > >
> > > >
> > > > Best regards
> > > >
> > > > Heinrich
> > > >
> > > >
> 
> 
> 
> -- 
> Masami Hiramatsu

      reply	other threads:[~2021-06-03  6:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03  2:17 [PATCH] efi: Restrict the simple file system protocol to support only FAT Masami Hiramatsu
2021-06-03  2:27 ` Masami Hiramatsu
2021-06-03  2:50 ` AKASHI Takahiro
2021-06-03  3:53   ` Masami Hiramatsu
2021-06-03  4:03 ` Heinrich Schuchardt
2021-06-03  4:57   ` Masami Hiramatsu
2021-06-03  5:15     ` Heinrich Schuchardt
2021-06-03  5:39       ` Masami Hiramatsu
2021-06-03  6:14         ` Heinrich Schuchardt
2021-06-03  6:52           ` Masami Hiramatsu
2021-06-03  6:24         ` Ilias Apalodimas
2021-06-03  6:36           ` Masami Hiramatsu
2021-06-03  6:47             ` 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=YLh670FCA67myCut@Iliass-MBP \
    --to=ilias.apalodimas@linaro.org \
    --cc=agraf@csgraf.de \
    --cc=grant.likely@arm.com \
    --cc=jesper@schmitz.computer \
    --cc=masami.hiramatsu@linaro.org \
    --cc=sakamoto.kazuhiko@socionext.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=vincent.stehle@arm.com \
    --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.