Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux