On Fri, Sep 2, 2022, at 4:47 AM, Richard Brown wrote:
Your assumption is wrong.
Any rpm is installed as root.
Any rpm can introduce new modules which result in modifications to /boot.
Are there examples of this actually happening? Or is it entirely hypothetical?
Any rpm script can modify whathever it wants.
Same for /boot/efi but it's excluded from the snapshot regime. Why is this risk acceptable? But two additional files per retained kernel version is an unacceptable risk?
No restriction we could impose in our own packaging would translate to 3rd parties. 3rd party kernel modules are, despite the wishes of the Kernel development community, used by a large proportion of Linux users.
Therefore any rollback mechanism needs to suspect unexpected alterations to /boot, hence why our typical btrfs snapshotting approach integrates it as part of the whole system.
There must be some limit to this. Because already $ESP is excluded. And if RPM scripts can do arbitrary things to $BOOT then it can do arbitrary things to snapshots on the system root, it's also a much bigger and more valuable target. A strong case can be made that MAC should disallow RPM from touching $BOOT $ESP $XBOOTLDR, only allowing privileged programs to do that. Constraints.
Constraints cannot be imposed on 3rd parties, but 3rd party kernel modules are a thing, as already mentioned.
Are you really going to tell everyone they cant have NVIDIA drivers any more?
100% 3rd party RPMs do not need to touch $BOOT directly. They install a module on the system root, add a dracut module, add or suggest to add a boot parameter, and its other tools that actually do that, rolling in the changes into the initramfs. But it's still dracut writing to $BOOT not an RPM inserting arbitrary kernel modules.
But as Thorsten pointed out, just keeping excess kernels around is not enough.
/boot is not some magical directory that exists in isolation from the rest of the operating system.
It's entirely possible that a kernel once loaded may depend on other modules, libraries, and files elsewhere in the filesystem.
I understand. There could be a kernel version with multiple variant initramfs's. A way to match the "generation" of the initramfs with system root would be needed.
Which is why we treat /boot as part of the whole operating system, and ensure that when someone rolls back they get the OS, including /boot, exactly as they used to have it.
No one wants to go from a known-working-bootable system to a broken system and then onward to a half-rolled-back-hybrid of /root and /boot being different from how they had it before.
Yeah I understand the logic. And BLS does not proscribe using Btrfs for $XBOOTLDR. The question is about tradeoffs, having Btrfs track /boot changes versus another mechanism. And the drawback of providing signed efifs drivers in order for $XBOOTLDR being anything other than FAT.
People want their system restored back to the state they knew worked..which means rolling back /boot in sync with the rest of their system.
I doubt any users care about rolling back /boot specifically. But rather the mechanism ensuring the pairing of kernel+initramfs+/usr is trustworthy. -- Chris Murphy