Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread ljknews
At 9:02 AM -0700 4/3/06, Crispin Cowan wrote:

 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.

I will admit to not knowing much about hardware, but you seem to be
discussing a TCB implemented in software.

Consider the VAX/Alpha/Itanium on which VMS runs.  As a user program
I access pages, but I don't think of them in those terms.  I think of
them as Sections (some are Global) which contain the read-only part
of one shareable image, my own DCL symbols, etc.  Those sections to
which I have access are in my virtual address space protected so I
have that access to which I am entitled.

What is disturbing about that hardware ?  Is it the fact that the
operating system is really setting individual page protections rather
than a whole segment at a time ?

I realize you probably want more levels and compartments, but that
does not seem to me to make the task untenable.  Educate me.
-- 
Larry Kilgallen
___
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


RE: [SC-L] Segments, eh Smithers?

2006-04-04 Thread Michael S Hines
Or consider the IBM Mainframe and z/OS Operating Systems - protected memory and 
paging
together - also privileged programs vs. application programs, also prefetched 
programs vs
loaded on demand programs.   

Mike Hines
Mainframe Systems Programmer
---
Michael S Hines
[EMAIL PROTECTED] 

___
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


Re: [SC-L] Segments, eh Smithers?

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

 * [...]
 * [...]
 * Someone develops a security kernel that effectively fakes
   segmentation in software using conventional pages, *and* they
   get it evaluated up to EAL7.

Strictly speaking, you don't need to have it evaluated for it to be
high security.  Evaluation does not give the security; it gives
confidence in the security (or lack thereof, if it flunks).

Okay, okay, /nitpick

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
___
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


Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread karger

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 

Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread Blue Boar

Crispin Cowan wrote:

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.


... What?

I thought I had the right x86 brain-damage, and knew what segments were. 
 But it doesn't sound like what you are describing.  My memory of 
segments has to do with a painful way to address 64K at a time on 16-bit 
DOS.  As opposed to a nice flat 32-bit (or more) address space.


Are you proposing that were I to access a memory address with DS: that I 
get one set of privs, and if I used ESI: I get a different set?


And what does that have to do with paging, which I thought had to do 
with mapping between physical and logical memory?


I'm not trying to flame you Crispin, I'd be willing to bet money that 
I'm the one who knows less in this area.  But I don't think you're 
explaining what you are getting at well.  Please spell it out for me.


BB
___
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


Re: [SC-L] Segments, eh Smithers?

2006-04-04 Thread Steven M. Bellovin
On Mon, 03 Apr 2006 09:02:27 -0700, Crispin Cowan [EMAIL PROTECTED]
wrote:

 
 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.
 
I'll respond more later to the rest of your post, but this merits
comments now.

First, segmentation and paging are not mutually exclusive.  Multics
itself used both; I believe that Pentiums are also capable of both.

Second, the two concepts serve different purposes.  Segments are a
user-visible concept (and the key point is that the hardware address
arithmetic does not have a carry between the high-order bit of the
offset into the low-order bit of the segment number); paging is
(mostly) invisbible to the user and primarily is used to (apparently)
expand physical RAM.

The problem with segmentation, though, is that it does limit the (easy)
size of an object.  Think back to the 286, when segments are much
smaller.  64-bit machines are a great place to use segments, though,
since it's (probably) at least 10 years before we run into the problem
again...

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
___
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


RE: [SC-L] Segments, eh Smithers?

2006-04-04 Thread Aleksander P. Czarnowski
Some quick thoughts on this subject regarding x86 architecture:

- I think we need to define better the term segment, because you also have
selectors in case of flat mode 
- secondly you can provide some protection mechanism using not only rings
but also memory pages and descriptor check, page directory check and page
check itself
- it's not only the problem of protecting memory areas but also what is a
privilege instruction - for example sidt or sldt opcodes used today for
identifying VMWare-alike environments
- accessing other ranges of memory like I/O ports 

Just my 2 cents...
Regards,
Alex Czarnowski
AVET INS

___
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