[OpenIndiana-discuss] 3737 days of uptime

[Rennie Allen]

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" <jason at 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.ml at 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 at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>_______________________________________________
>OpenIndiana-discuss mailing list
>OpenIndiana-discuss at openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss