I worked for QNX back in the early 2000's. At that time QNX had a fairly complete design for performing kernel upgrades on a live system. Because QNX is a microkernel, this was doable. I can't get too deep into the details, but essentially it required a set of permanently reserved memory pages for the incoming kernel .text, as well as a runtime requirement that sufficient free RAM existed to hold a copy of the current kernel data structures at the time of the upgrade. The ability to upgrade the layout of kernel data structures was addressed. Because (in QNX) all drivers are implemented as user processes there was no need to interfere with them during the upgrade process (it was completely transparent to interrupt handlers - i.e. zero latency impact for interrupt handlers). There was a temporal disruption to the scheduling of threads waiting on interrupts at the moment of the upgrade and to threads being scheduled as a result of kernel timers, but it was small and predictable based on the size of the allocation of kernel data structures at the time of the upgrade.
I believe that by the late 2010's any truly industrial strength O/S will require the ability to handle live kernel upgrades. On a microkernel O/S it is highly likely that the kernel will never need to be upgraded to remediate a security issue (the QNX kernel itself is EAL4 certified, and only needs to insure that message passes are encrypted and only accessible to correctly credentialed threads in order to remain that way over the long haul). The only plausible requirement to upgrade the kernel for security reasons would be if the message crypto algorithm had been permanently cracked. Privilege escalation issues, etc., would all have to occur via vulnerabilities in user space processes (which can be easily dynamically patched). Basically, my point here, is that it is erroneous to assume that servers should have to be reset in order for security to be maintained over the long haul. On 3/20/13 12:06 PM, "Jason Matthews" <ja...@broken.net> wrote: > >long uptimes are not hard to achieve. i bet if i got my old sparc ipx out >from college days and booted it the system would report about thirteen >years if uptime. i think i last used it in the summer of 2000. > >i "shut it down" last time by putting it to sleep. when it boots, >assuming battery is good shape, it should have all that elapsed time as >uptime. > >but you right, i didnt apply any patches. something tells me its as >secure as the day i packed it away :) > >j. > >Sent from Jasons' hand held > >On Mar 20, 2013, at 4:55 AM, Sašo Kiselkov <skiselkov...@gmail.com> wrote: > >> On 03/20/2013 12:32 PM, Edward Ned Harvey (openindiana) wrote: >>> It would only bring a tear to my eye, because of how foolishly >>> irresponsible that is. 3737 days of uptime means 10 years of >>> never applying security patches and bugfixes. Whenever people >>> are proud of a really long uptime, it's a sign of a bad sysadmin. >> >> 1) Reboot is only required when applying kernel patches or big >> clusters which affect core services (and the admin is using BEs). >> >> 2) Not all machines are web-facing and thus don't necessarily need >> regular security patching. >> >> 3) If it ain't broken, don't fix it. >> >> Not everybody can afford the luxury of periodic maintenance downtime and >> certain systems are required to be 100% available, though I will admit >> that these are few and far between (and in most cases a good hot-spare >> policy will take care of this). >> >> -- >> Saso >> >> _______________________________________________ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss > >_______________________________________________ >OpenIndiana-discuss mailing list >OpenIndiana-discuss@openindiana.org >http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss