|
Top-level
 @vurpo nope, of course boot assessment would catch this. Key is just that you "pin" enough as part of an attempt, and thus can revert sufficient parts to get things working. On Linux you'd pin kernel *and* initrd at the very leas, and in the model i propose even the entire /usr for each attempt, to maximize coverage of the assesment logic. 7 comments
 @bse @pid_eins @vurpo If you deliberately bypass the system integrity and safety features, then they won't save you. It doesn't matter what those features are. If you blindly sign initrds, checking won't help you. If you blindly mark a boot config as good, or if you replace your rollback image, or whatever... The system won't save you from yourself infallibly. You'll still want staging, and monitoring, and disaster recovery. @pid_eins @vurpo Since both entries would be using the same kernel and hence use the same /lib/modules/$(uname -r)/, you need a mechanism to have multiple versions of your modules folder. If you're serious about preventing older boot entries from breaking retroactively, i think full system snapshots are the only option. Short of that, there might be some compromises like bundling a kernel and all modules, which of course does not protect userspace, but might be easier for commonly used distros. |
Gregory's Server
@pid_eins @vurpo I would assume you also have to pin /lib/modules, or better get rid of that relic completely and move modules inside the UKI?