public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox