Bug 2106706

Hello, /boot on vfat is not supported intentionally, since the vfat file system doesn't support for example extended attributes. There is no plan to support /boot on vfat and anaconda shows a correct error message. Please use for example XFS or ext4 for /boot.

I'm closing this bug.

> Hello, /boot on vfat is not supported intentionally, since the vfat file
> system doesn't support for example extended attributes.

What is the use case for extended attributes on /boot?

I can only think of selinux.  That doesn't make sense though.
There is no need for fine-grained access control for /boot.

Only root is allowed to update /boot, period.
Whenever you want allow public read access to /boot is debatable.

Given there are no secrets on /boot and everybody can download
the content by fetching the kernel rpms I don't see how
restricting /boot read access helps improving security much.
On the other hand the same is true for /boot/efi which actually
is only readable for root on a default install.

> There is no plan to
> support /boot on vfat

As far I know there are plans to change that.
Cc'ing Peter Jones + Alexander Larsson.

> Please use
> for example XFS or ext4 for /boot.

Requiring the boot loader being able to handle the complexity
of a journaling file system IMHO isn't a wise choice.

(In reply to Gerd Hoffmann from comment #2)
> > Hello, /boot on vfat is not supported intentionally, since the vfat file
> > system doesn't support for example extended attributes.
> 
> What is the use case for extended attributes on /boot?
> 
> I can only think of selinux.  That doesn't make sense though.
> There is no need for fine-grained access control for /boot.
> 
> Only root is allowed to update /boot, period.
> Whenever you want allow public read access to /boot is debatable.
> 
> Given there are no secrets on /boot and everybody can download
> the content by fetching the kernel rpms I don't see how
> restricting /boot read access helps improving security much.
> On the other hand the same is true for /boot/efi which actually
> is only readable for root on a default install.

/boot contains crucial files to boot the system, so security is a valid reason - for example initramfs may contain sensitive content.

> 
> > There is no plan to
> > support /boot on vfat
> 
> As far I know there are plans to change that.
> Cc'ing Peter Jones + Alexander Larsson.

OK, I'm interested to know the justification.

> 
> > Please use
> > for example XFS or ext4 for /boot.
> 
> Requiring the boot loader being able to handle the complexity
> of a journaling file system IMHO isn't a wise choice.

Then ext2 could work.

(In reply to Jan Stodola from comment #4)
> (In reply to Gerd Hoffmann from comment #2)
> > > Hello, /boot on vfat is not supported intentionally, since the vfat file
> > > system doesn't support for example extended attributes.
> > 
> > What is the use case for extended attributes on /boot?
> > 
> > I can only think of selinux.  That doesn't make sense though.
> > There is no need for fine-grained access control for /boot.
> > 
> > Only root is allowed to update /boot, period.
> > Whenever you want allow public read access to /boot is debatable.
> > 
> > Given there are no secrets on /boot and everybody can download
> > the content by fetching the kernel rpms I don't see how
> > restricting /boot read access helps improving security much.
> > On the other hand the same is true for /boot/efi which actually
> > is only readable for root on a default install.
> 
> /boot contains crucial files to boot the system, so security is a valid
> reason - for example initramfs may contain sensitive content.

/boot is unencrypted, so there should be no expectation of security for content of any files stored on it.

I posted the initramfs example because I remembered the following CVE we had to deal with in the past:
https://bugzilla.redhat.com/show_bug.cgi?id=859448

On the other hand, the installer allows to disable SELinux on the installed system (by "selinux=0" on the kernel command line), so if the user wants to have a system with SELinux disabled, then using vfat for /boot is also fine from this point of view.

Hi Gerd,

could you please tell us about the priority of the issue. Is there a customer case or are we breaking a workflow by this?

> could you please tell us about the priority of the issue. Is there a
> customer case or are we breaking a workflow by this?

No concrete use case yet.  We are investigating how we can simplify
the boot workflow for confidential computing.  In particular the way
grub2 handles TPM measurements is rather problematic, and checking out
alternatives is much easier when the EFI firmware is able to read the
filesystem where the kernels are stored on.  That allows to use other
simpler boot loaders which don't bring their own filesystem drivers,
or to not use a boot loader at all and add the kernel directly to the
BootNNNN EFI variables instead.

(In reply to Jan Stodola from comment #6)
> I posted the initramfs example because I remembered the following CVE we had
> to deal with in the past:
> https://bugzilla.redhat.com/show_bug.cgi?id=859448

Storing machine-specific configuration or evens secrets in the initrd is
another problem which needs adressing.  CoreOS ships a initrd by default
instead of generating it on the installed system, which is a step into the
right direction.  No config/secret is in there.  Also we know the hashes
of the bits we ship, so measurements are much more useful because we can
actually verify that the initrd hasn't been tampered with.

Ideally we'll go further and ship unified kernel images (aka all-in-one efi
binary with kernel, initrd, cmdline and secure boot signature).

[ not relevant to this bug, just giving some more background info ]

Hi Gerd,

thank you for providing us all the information. We decided that we don't want to implement this feature. It seems that there is not a strong use-case now and we would also need ACK from bootloader team first. Because of that I'm closing this issue now. Feel free to reopen if you don't agree with the decision.