On Sat, Jun 24, 2023 at 08:04:46PM +0200, Ard Biesheuvel wrote: > The efivarfs pseudo-filesystems exposes all EFI variables as > world-readable, and carries some logic to prevent accidental deletion > from bricking a system, by setting the immutable flag on all variables > whose purpose is unknown. > > When the RandomSeed support was added, we decided not to expose this > variable via efivarfs at all, given that the kernel itself was intended > to both produce and consume it directly, without involvement from user > space. This removed the need to deal with the world-readable default > permissions (which would be undesirable for the random seed that will be > used on the next boot), as this would require special handling of the > RandomSeed variable, given that we cannot restrict those permissions for > all EFI variables without running the risk of breaking user space. > > Now that the producer side of this mechanism has been reverted [0], it > is no longer possible to set the RandomSeed variable at all. Whether > and how we will replace the in-kernel producer with something more > robust is still under discussion, but in the mean time, let's relax the > efivarfs restriction on any direct access of the variable, and instead, > ensure that it is created as user read-write only, both when the EFI > varstore is enumerated (at mount time) and when the file is created > explicitly by user space. > > Also ensure that the file is not created with the immutable flag set so > that user space can manipulate the file as usual. Hm, I'm still not so sure we want to open the pandora's box of having to deal with userspaces writing this. Maybe we can keep it in the kernel but delay it until a little later in boot so it doesn't cause an outright bootup hang? Or just bite the bullet and do it at shutdown? I think I'd prefer just doing it in a delayed workqueue in late/post boot though. (On the topic of this patch, technically this only needs to be write-only, not read-write, right?) Jason
