PGN cites many of the things that Multics did right and history did not
follow. Most of these issues are sufficiently entrenched in legacy
hardware and software that there is little chance to change them any
time soon.

Of particular and critical interest at this juncture is segmented
memory. Graybeards love segmented memory, and modern Linux kidz hate
segmented memory. A close friend has observed to me that 100% of A1
evaluated operating systems (both of them :) used segmented memory. In
stark contrast, all modern operating systems use paged memory instead.
Apparently there was a movement to hack segments into the Linux kernel a
year or so ago, but it was quickly shouted down.

Even if we could convince kernel developers to try segments, the only
hardware architectures left that still support segmented memory (x86)
are about to go extinct. x86-64 offerings from Intel and AMD have
removed the segmented memory functionality from the instruction set, and
they have no plans to put it back. Why should they, if approximately
zero operating systems will use the facility. Conversely, why should OS
developers muck about with segmentation if hardware supporting it is
about to become extinct? A classic chicken/egg problem in reverse, where
it is possible to do now, but about to die out because no one cares.

This leads me to 2 questions:

   1. Is it remotely possible to start a ground-swell of interest in
      segmentation, get keen software running on x86 CPUs, and do it
      soon enough to interest Intel or AMD in re-enabling segmentation
      support in their future x86-64 CPUs?
   2. If the answer to 1 is "no", then is it possible to build a kernel
      that offers the A1/EAL7 assurance of something like a Multics
      kernel, does it with pages instead of segments?

That second question is actually pretty technically deep. What is so
different about paged memory systems that makes them harder to secure
than segmented memory systems? My conjecture: it is the granularity of
the memory blobs. Consider:

    * In a segmented system, you have a small number of fairly large
      memory objects (segments). Segments are hefty enough that they can
      be of variable size, and also can have security tags describing
      their security level at multiple levels. So a given segment can be
      tagged as being security level 1, 2, 3, and so forth, and the TCB
      need only check the level before granting or denying access.
    * In a paged system, in contrast, you have a very large number of
      much smaller memory objects (pages). Pages are simple, even having
      fixed size. Fixed size wastes memory, but no one cares because the
      pages are small enough that it doesn't hurt much. Because pages
      are simple, you cannot tag them with a bunch of different security
      levels. For that matter, x86 architectures only recently got a
      (kind-of) ability to distinguish between read and execute
      permissions per page, so asking associate and store security
      levels per page in hardware is likely more than the TLB can handle.

So, if we hope to have a truly high security operating system in our
lifetimes, then one of several things will have to happen:

    * Intel and/or AMD reinstate segmentation support in x86-64.
    * Intel and/or AMD introduce a fancy paging hardware system that
      supports multiple security levels per page, *and* a secure kernel
      is developed that takes advantage of these page security levels to
      give us highly secure memory access control.
    * Someone develops a security kernel that effectively fakes
      segmentation in software using conventional pages, *and* they get
      it evaluated up to EAL7.

None of which seem likely.

So, I suspect that my career path of providing retro-fit security for
fundamentally insecure systems like C (StackGuard) and the UNIX family
(AppArmor) might have some legs to it :)


Peter G. Neumann wrote:
> Der Mouse is barking up the right rathole.
> Having cut my security eye-teeth in Multics from 1965 to 1969, I am
> continually drawn back into discussions of what Multics did right that
> has been systematically (!) ignored by almost all subsequent operating
> systems.  For the younger folks among the SC-L audience, let me mention
> a few of the architectural strengths.  There were no buffer overflows in
> the stack, because anything out of the stack frame was not executable.
> The ring-structured domain architecture and file system access controls
> permitted straightforward sandboxing.  Dynamic linking and revocation
> were fundamental.  Segmentation and paging enabled layers of virtual
> machines and protected virtual memory.  The I/O system had virtual
> stream names, virtual I/O, and common device-driver software where
> appropriate, coupled with separate hardware for the input-output
> controller (GIOC).  The programming language was the stark EPL subset of
> PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to
> have avoided some of the characteristic programming errors that are
> still common today.  No software was written until there was an approved
> specification, with well defined interfaces and exception conditions
> that were explicitly characterized in EPL.  And so on into a visionary
> sense of a future that has been largely lost for may perceived reasons,
> some of which are bogus, some of which are just seriously short-sighted.
> *** END SOAPBOX ***
> I'm sure this message may generate all sorts of Ifs and Ands and Buts.
> But the Butt we are kicking is our own.
> Cheers!  PGN
> _______________________________________________
> Secure Coding mailing list (SC-L)
> List information, subscriptions, etc -
> List charter available at -

Crispin Cowan, Ph.D.            
Director of Software Engineering, Novell

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -

Reply via email to