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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php