3 ms·
> Can you explain this a bit? I'm not familiar with the particulars of firmware, but I'm having a hard time imagining why any userspace program would expect a f
by the_mitsuhiko 11y ago
> Can you explain this a bit? I'm not familiar with the particulars of firmware, but I'm having a hard time imagining why any userspace program would expect a firmware partition to be writable.
Best example of why you need to have it RW: if uefi is in fast boot, the only way to actually enter uefi is to boot an OS and have the OS set the uefi variables so that it goes into the firmware screen on next restart. This is (on Linux) done by changing something in that virtual filesystem.
> certainly I'd have a hard time believing that they would need it to be mounted and writable all the time.
You could probably remount it, but that also means that you all the sudden have concurrency problems with that operation. So not really ideal.
- gnud 11y agoFor this particular example, wouldn't this be best solved with a separate runlevel for "reboot into UEFI"? Stop all daemons, remount all normal filesystems read-only, remount UEFI RW, write variable and reboot.
- EmanueleAina 11y agoPossibly, but what happens if a faulty script does a `rm` too much in that short time window? The kernel fix prevents that, using mount flags alone only restrict the vulnerability but it doesn't make it go away.