Servers can avoid reboots for long periods of time, but not forever.
I wouldn't call it a 'vulnerability', but it does bring up something that can sometimes cause problems, and that is, the longer a system runs, the less confidence administrators tend to have of it coming back up cleanly after a reboot. I've seen servers go years between reboots even without this feature because they weren't being religiously patched. (They were fairly stable systems that weren't externally facing). The longer they'd go, the less confidence you'd have that you actually knew about any changes that had been made to the systems. Additionally, having long uptimes could occasionally mask hardware issues. I've seen AIX servers that pretty much ran continuously from the time the OS was installed until the next update, which in the case of these systems was about 4-5 years. For some, once the hard drive would spin down, they just wouldn't spin back up, so they were fine as long as they were chugging along, but the moment you tried to reboot, you were in serious trouble..
If your change control procedures are good, you can stay on top of any configuration changes that have occurred, but sometimes it's hard to remember stuff from more than a year back.
It might be required that hot updates (handoffs) be made only between certain versions or releases of the kernel, the kernels themselves containing the requisite handoff code.
So a requirement for using hot updates would be to keep the system hot updated every so many releases of the kernel. Otherwise you have to update in the normal manner, with a reboot.
Yes, I agree with all.
Except the conventional wisdom of applying updates without fully testing them in test systems exhaustively and letting them “age”.
But on that practice I am pretty much contrarian to all admins.
Admins, I get it, have the job of applying system updates.
But they don’t have the authority to order exhaustive system tests... which would be whole projects in and of themselves that would involve business users and other IT folks, significantly... with no perceived benefit for the business user community and use of tons of their time and effort.
So, in lieu of comprehensive system testing... sys adms simply have to apply system updates on their own schedule.
The “conventional wisdom” that has been pushed on everyone is to continuously apply every update as fast as possible, i.e., keep up.
Skip no updates, apply them all as they come out as soon as possible.
Unfortunately, every update is not secure.
Therefore, the apply all as fast as you can practice actually guarantees that every insecure update will get applied at some point in time.
So the admin does not avoid any vulnerabilities, he installs every one, followed by its fix at some point, along with succeeding new vulnerabilities.
The best strategy for security, of course, would be to search for, test for, and build configurations that had a combination of updates that was secure, as much as can possibly be determined by researching the vulernabilities of each piece of software and its updates. Every server configuration deemed ready for production would have a combination of updates applied such that the system either had no vulnerabilities or had workarounds that were properly implemented for those that were known.
But alas, this is too much work.