On Wed, Dec 21, 2022, at 6:53 AM, Vitaly Zaitsev via devel wrote:
On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> Why shouldn't FAT be used for /boot. In an EFI world, /boot
> is used for the same functional pupose as the ESP, which is
> already going to use FAT.
Doesn't support links, lournaling and ACLs.
What's the use case? Is it a nice to have or is it a hard requirement and why?
The Linux FAT driver does support SELinux context with a mount option. We aren't using
that right now but we can have a suitable SELinux label enforced file system wide on ESP
and XBOOTLDR.
Everyone can do whatever they want with the files, and a trivial
power
outage can easily wipe out all of its contents.
This is a rare but real problem. I think we should be looking at ESP and XBOOTLDR updates
doing A/B updates, i.e. write the updates to temporary files or directories and then use
renameat(2) which is atomic at the VFS layer, and should get pretty close to atomic at the
FAT layer to the degree that worse case scenario we have either the old *and* new files
following a crash. Ideally we'd get old *or* new. But that's probably not possible
with FAT. But we can still boot.
> Such drivers would need to be signed to be used
> under SecureBoot, thus expanding the set of components you
> need to audit & trust for security purposes.
These drivers are backports from the grub2 code. If we trust GRUB, we
can trust them too.
Fedora Infra can be configured to sign the contents of the efifs package
with a Fedora SB key.
Yeah but then try getting all the distros to agree on signing efifs. How many distros are
there? It's not unfair to say all distros should be able to put their signed efifs
drivers on the ESP because that's the only way their bootloader can read
loader/entries to properly draw a boot menu.
--
Chris Murphy