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:24:56 +0300 [thread overview]
Message-ID: <YLh1uKKUyqptWEPw@Iliass-MBP> (raw)
In-Reply-To: <CAA93ih2iangTi1zNkumrk665NHv=CmwcdU=LE1UxUaDDvBqgCA@mail.gmail.com>
[...]
> >
> > 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.
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
> >
> >
next prev parent reply other threads:[~2021-06-03 6:25 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 [this message]
2021-06-03 6:36 ` Masami Hiramatsu
2021-06-03 6:47 ` 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=YLh1uKKUyqptWEPw@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