Linux live kernel patching

[tanked]

http://www.zdnet.com/article/no-reboot-patching-comes-to-linux-4-0/

Is something like this being worked on for FreeBSD? Do we event want something like this i.e. is it an attack vector?

 

[Cthulhux]

Yes, it is; but, even worse, it's a potential crash vector. Would you replace your car's motor while driving on the highway?

 

[gkontos]

Yes, it is; but, even worse, it's a potential crash vector. Would you replace your car's motor while driving on the highway?

No, but fighter jets get refueled while flying all the time so, your example is not very good....

 

[Cthulhux]

Refueled but not equipped with a new engine. A kernel roughly equals the engine, not its fuel (the userland; which works on the fly indeed).

 

[roddierod]

OpenVMS/VMS used to do this and it was known for it's stability. Not say the Linux method is going to be rock solid or anything, just that if engineered correctly and implemented properly it can be done. But then again I don't think this is being engineered by DEC engineers.

 

[gkontos]

Live patching is really something interesting in general. I would really love to see some of my FreeBSD machines having good uptimes. Right now, the only reason why I need to reboot them is only for applying KERNEL patches or system upgrades.

 

[John Call]

Live patching is really something interesting in general. I would really love to see some of my FreeBSD machines having good uptimes. Right now, the only reason why I need to reboot them is only for applying KERNEL patches or system upgrades.

Hmm. I turn off my computers when I don't need them, but only the PCs. Are you talking about mission-critical servers? Because otherwise, long uptime is just a waste of electricity for no added benefit, assuming you do not use your desktop 24/7.

 

[gkontos]

Hmm. I turn off my computers when I don't need them, but only the PCs. Are you talking about mission-critical servers? Because otherwise, long uptime is just a waste of electricity for no added benefit, assuming you do not use your desktop 24/7.

Welcome, you are a new member so I am not going to have you for dinner, yet...

I am referring to servers.

 

[protocelt]

I would love to see this in FreeBSD as well for both server and desktop systems.

 

[gkontos]

I would love to see this in FreeBSD as well for both server and desktop systems.

KERNEL patching applies the same to both servers and desktops.

 

[protocelt]

KERNEL patching applies the same to both servers and desktops.

I realize that. I suppose I should have worded my reply better, my bad. I personally feel it would be useful for both server and desktop systems.

 

[NewGuy]

I would like to see live patching for FreeBSD kernels. Updating kernels for security patches is about the only reason I reboot my FreeBSD system. Since the servers get scheduled reboots on a regular basis (perhaps once per quarter) it would be nice to be able to live patch the kernel and put off a reboot until the scheduled maintenance window. The current approach, rebooting to apply kernel security updates, interferes with the regular schedule.

It's not a huge issue, but live patching would provide a nice feature, one added convenience.

 

[ANOKNUSA]

How would this even work on FreeBSD? Wouldn't it require a different approach to how the kernel is integrated into the base system? I confess I don't know enough about the internals of the system to really say, but it seems dubious. In any case, I've never understood what drives people to undertake the Quest for Infinite Uptime, that mythical artifact that drives people to make statements like this:

With Linux 4.0, you may never need to reboot your operating system again.

Never, never, never take such grandiose statements seriously. In any situation. Ever.

 

[kpa]

How would this even work on FreeBSD? Wouldn't it require a different approach to how the kernel is integrated into the base system? I confess I don't know enough about the internals of the system to really say, but it seems dubious. In any case, I've never understood what drives people to undertake the Quest for Infinite Uptime, that mythical artifact that drives people to make statements like this:



Never, never, never take such grandiose statements seriously. In any situation. Ever.

Of course not, anyone who is familiar with OS design on a deeper level knows that memory fragmentation is an unavoidable problem and eventually the system will run out of large enough chunks of memory to allocate for the system. It might take years of uptime to run out of memory for a system that isn't that busy but it will happen eventually.

 

[gkontos]

Nobody is saying that a system should have an infinite uptime. Being able to patch the KERNEL without rebooting can be a good motivation for systems that do require longer uptimes.

Aside from that, in Linux kernel patching occurs much more often than in FreeBSD. It is difficult to maintain a system, security wise, if you can't plan for a reboot at least once in ~45 days.

 

[Crivens]

Of course not, anyone who is familiar with OS design on a deeper level knows that memory fragmentation is an unavoidable problem and eventually the system will run out of large enough chunks of memory to allocate for the system. It might take years of uptime to run out of memory for a system that isn't that busy but it will happen eventually.

That's what MMUs and IOMMUs are for, together with virtual memory. It can be done, but it is pretty complex. And one mistake, one compromise, one 'don't care' will screw things up.

What I would go for would be some way of freezing the complete user land and restarting it from that point with a new kernel in place. On Linux I had seen something called cryopid, which would do that for one process. Imagine to do something like that for a process tree - say - we freeze init and all it's children only to resume them on a new kernel or different machine. If done fast enough, you would even keep network connections alive while doing this.