Hey all! 
I was just wondering if there could theoretically be kernel livepatching in fedora silverblue one day?
Any thoughts?
Have a wonderful day!
1 Like
Theory aside probably not practically, because the live patches from kernel to kernel really work best when created by hand with care, and we don’t have the resources to do that.
But I’m curious on the question in theory too, since Silverblue uses reboots to apply all os-level updates, it’d be kind of strange to go to extensive lengths to hot-patch the kernel when systemd or glibc or anything else requires a reboot. What’s the use situation you’re envisioning?
2 Likes
There is the experimental option to set the filesystem to “livefs”. rpm-ostree ex livefs which makes the current booted commit into a writable system.
2 Likes
Thanks for your answers! I was just wondering if kernel livepatching could still be the cherry on the cake for SB at some point, as it also makes the time between reboots even more secure. 
But I realize that the common use cases tend to suggest CoreOS with self-initiated reboots.
I think that live kernel patching is only useful for maintaining uptime on servers that need critical security fixes. Since Fedora Silverblue is a desktop OS behind a firewall, live patching really does not have a lot of practical use cases that I can think of.
Even there I question the validity of using live patching. If it’s important enough to live patch, it’s important enough to get a redundant server. Once you get a redundant server you just upgrade the standby, fail over, and upgrade the new standby. Boom, no downtime
This may or may not be slightly off topic but…
I don’t think that the “livefs” feature interrupts or migrates anything in memory, and therefore, daemons and such that were started during the previous commit are still running. This is implied from Colins post when he states that you need to restart NetworkManager to use the new version.
So in this situation, I don’t think “livefs” applies any kernal updates live. But I could be wrong 