Secure Coding mailing list archives
Segments, eh Smithers?
From: karger at watson.ibm.com (karger at watson.ibm.com)
Date: Tue, 04 Apr 2006 13:39:24 -0400
My comments are interleaved below: Crispin Cowan writes:
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?
Actually, there are still current processors that have segments. The IBM zSeries and iSeries both have segments, and iSeries actually uses them. For those not up on the latest IBM trademarks, zSeries is the latest incarnation of the old 360/370 series mainframes, and iSeries used to be called System/38 and then AS/400. Also, Unisys still sells systems that are descendents of the old B5000/B6700 legacy.
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?
The DEC A1-secure virtual machine monitor was building an A1 system on the VAX which had no segments. It is certainly possible, although it is harder.
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.
Actually, the real benefit of segments is not the granularity so much as the isolation. The Alpha chip had separate read, write, and execute permission bits for every page table entry, and that was NOT a problem for the TLB. It was just the VAX and the x86 that had short-sightedly omitted an execute permission bit. Most other virtual memory processors had all three. It is just unfortunate that the two architectures that didn't became extremely popular, compared to all of the others. Where segmentation really helps is that you have a variable length structure that you cannot address off the end. If you quote a segment offset that is bigger than the maximum size of the segment, you either get an immediate addressing error, or the address wraps around within the segment. On the Burroughs B6700, you got the addressing error. On Multics, the address wrapped around within the same segment. In either case, a bad segment offset could NOT cause you to reference a different protected object. On the DEC A1-secure VMM, we put guard pages around objects, but that is NOT sufficient. A reference that goes way beyond the guard page would still work. The zSeries (360/370) segments have the same problem. You can address off the end of one segment and into another segment. That was not possible on the Multics processors. The result is that you have work harder to avoid buffer overflows, either on a purely paged machine or on a segmented machine that allows flowing into another segment. By contrast, it was not possible to reference beyond the end of a B6700 or Multics segment. The hardware would stop you.
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.
The odds of segments coming back in Intel or AMD are VERY small.
* Someone develops a security kernel that effectively fakes segmentation in software using conventional pages, *and* they get it evaluated up to EAL7.
Doing a high assurance security kernel without hard segment boundaries is definitely possible. It is just harder. The DEC VMM was one such system. KVM/370 was another. SCOMP and the PDP-11/45 also had segments that you address off the end and into another segment. They both had high assurance systems built for them.
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 :)
Getting rid of C seems even less likely than bringing segments back.
Crispin 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-- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com ------------------------------ _______________________________________________ SC-L mailing list SC-L at securecoding.org http://krvw.com/mailman/listinfo/sc-l End of SC-L Digest, Vol 2, Issue 52 ***********************************
Current thread:
- Segments, eh Smithers? Crispin Cowan (Apr 03)
- Segments, eh Smithers? ljknews (Apr 04)
- Segments, eh Smithers? Michael S Hines (Apr 04)
- Segments, eh Smithers? der Mouse (Apr 04)
- Segments, eh Smithers? Blue Boar (Apr 04)
- Segments, eh Smithers? Steven M. Bellovin (Apr 04)
- Segments, eh Smithers? Aleksander P. Czarnowski (Apr 04)
- <Possible follow-ups>
- Segments, eh Smithers? karger at watson.ibm.com (Apr 04)
- Segments, eh Smithers? ljknews (Apr 04)