Linux is not reliable enough?

[Robert Kaiser]

Am Montag, 26. Juli 2004 15:46 schrieb Mark Chambers:
> But if you write drivers that don't crash the system then
> linux is not unreliable.

Its not just the drivers: every line of kernel code (and there are over a
million of those in linux) has the potential to crash the system. In order to
be *really* sure that the system is reliable, one would have to give all that
code a thorough examination. Depending on how "thorough examination" is
defined (and there are approved standards for this), this effort results in
costs that quickly make the question wether the OS's source code is available
for free, or will cost a few hundred kilobucks, a non-issue.

> The only operating system that doesn't allow a
> clever programmer to crash is one that doesn't do anything.  Microkernels,
> they say, allow you to do nifty things like replace the file system without
> rebooting.

This is not really a microkernel-specific feature. I believe Linux with its
kernel modules can do this as well.

The important thing about the microkernel approach is that it allows to build
OS functionality from components, where each component runs in its own
address space and only has access to the resources it needs to do its job. A
device driver only needs access to the registers of the device it is supposed
to handle, so it can only foul up this particular device (*). If such a
driver goes haywire, it *can* not affect, e.g. other driver's hardware or
memory: the bug remains local to the software that causes it. Such a failure
affects only the offending component itself and the software modules that
rely on the services this component offers.

The benefit of this approach for safety-critical systems is that one can
identify the components that are critical to the application. If a particular
application does not require a big deal of OS functionality, then only the
few components necessary to implement it need to be scrutinized. Other
components may well exist in the system, for example to support non-critical
parts of the application, because they can not affect the critical parts.

Don't get me wrong: I'm not saying a microkernel (or even QNX) is inherently
safer than Linux. However, if done right, it can give you the freedom to
trade functional complexity against functional safety.

> So that means you could swap in a buggy filesystem and destroy
> the data on your disc/flash.  Without rebooting.  Which is good since you
> won't be able to boot from your corrupted filesystem, which won't show up
> until the next power failure, while the poor nurse with a flashlight talks
> to a guy on the phone who assures her QNX can't fail.  So every OS, and
> every feature, has its pro's and con's.  The question for any CSA is not
> 'is this reliable' but 'can I make a reliable system using this component'?
> Will the OS eat itself, or do I only have to worry about the mistakes I
> make?  A carefully constructed linux system should be good for 5 or even 6
> nines of reliability.

This may be your gut feeling, but the CSA has to *prove* it for the OS he
chooses (at least he should have to, that is his responsibility).

(Honestly: would you fly in an aircraft whose steer-by-wire system is
controlled by Linux/QNX/any other OS (name please)?)


Rob

(*) There are some more issues here which I left out for brevity: If the
device being handled by a driver is capable of DMA, it *can* crash
everything. Therefore, such drivers need special consideration. Also, for
memory-mapped I/O, access permissions to device registers need to be enforced
by the MMU, so, if there are multiple devices with their registers within the
same physical page, they can not be protected from each other. Nevertheless,
the likelihood if a wild pointer causing spurious crashes is still greatly
reduced.

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser at sysgo.com
SYSGO AG
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/