Managed Code and Runtime Environments - Another layer of added security?

[u3902 at siliconkeep.com (Olin Sibert)]

While we're on Multics lessons, let's not forget upward-growing
stacks (which were a natural consequence of the segmented
addressing architecture).

Multics code was not immune to buffer overflows, but in most cases
the effect was blunted because the out-of-range index values could
only affect data beyond the current activation record--in contrast
with most linear addressing systems where an overflow is almost
always able to reach important values like the return address.

It is sobering to reflect how much of the current state of our art
was laid out clearly in 1969 by Peter's own "The Role of Motherhood
in the Pop Art of System Programing" paper and by the 1973
Saltzer/Schroeder paper "The Protection of Information in Computer
Systems".  These are always worth a read:
    http://multicians.org/pgn-motherhood.html
    http://www.cs.virginia.edu/~evans/cs551/saltzer/

  -- Olin Sibert

At 01:17 PM 3/29/2006, Peter G. Neumann wrote:
> Der Mouse is barking up the right rathole.
>
> *** BEGIN SOAPBOX ***
>
> 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)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php