On Tue, 25 Feb 2025 at 13:59, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > [added correct mailing list for bug report] > On Tue, 2025-02-25 at 12:10 +0000, Richard Hughes wrote: > > Hi, > > > > I'm not sure what I'm supposed to do about: > > > > commit 908af31f4896f2c0645031f8b74a89d3a8beb5b9 > > Author: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > Date: Sun Jan 19 10:12:12 2025 -0500 > > > > efivarfs: fix error on write to new variable leaving remnants > > ... > > > > It causes a regression in fwupd -- seen in > > https://github.com/fwupd/fwupd/issues/8495 and > > https://bugzilla.redhat.com/show_bug.cgi?id=2346831 so far -- and it > > seems broken for anyone (including me) updating to 6.14. > > OK, so the problem with this as a bug report is that it doesn't explain > what you're doing. However > > > I can work around the behavior in > > https://github.com/fwupd/fwupd/pull/8500 (which is also the arguably > > correct thing to do) but it's going to cause a panic as I have to get > > an updated fwupd out on all distros so we'll need releases for > > multiple branches. This code was introduced in the merge window for v6.14, which is due to be released end of March. How much time do you need? Derailing LVFS is the last thing I want to do, but we all know how this works: once a workaround is put in, it is never going to be removed. > > Reading the code in the fix, it looks like you were creating a file in > EFI (which is naturally zero length), then closing it (because glib gio > specifically has an API for this), then clearing the immutable bit and > then writing to it to actually create a variable? > > However, none of that dance is at all required. A newly created file > naturally allows writing on the file descriptor you used to create it. > It's only if you open it again that the entry becomes immutable. Should we be doing this in the first place? It makes sense for efivarfs to mark variables that it doesn't know about as immutable if they are present at boot - the original rationale here was systems with buggy firmware, where an inadvertent 'rm -r /sys/firmware/efivars/*' would brick the device. But the fact that a newly created file becomes immutable once you close and reopen it seems unnecessarily strict to me. (I am aware that this is orthogonal to the issue at hand, but it is something we might fix nonetheless)
