Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!email!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.os.minix
Subject: Re: Idea for sep. data & stack segs.
Message-ID: <1991Jun6.105936.6994@email.tuwien.ac.at>
Date: 6 Jun 91 10:59:36 GMT
References: <55426@nigel.ee.udel.edu>
Sender: news@email.tuwien.ac.at
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Lines: 29
Nntp-Posting-Host: nowhere.vmars.tuwien.ac.at

mike.irons@lynx.northeastern.edu writes:


>	I just had an idea that would allow (I think) seperate segments for the
>stack and data segments on Intel x86 (x >= 2). Have seperate, OVERLAPPING s
>segments. With this the pointers to the stack and data would be for different
>selectors, but the descriptors would address the same space. With this the stack 
>segment  'top' could be used to detect stack over-runs.

>	How hard, if workable, would this be?

It wouldn't be hard, but I don't see any benefit in it. Stack segments
always start at 64k (or 4G on the 386) and grow downward. If you want
to dereference pointers without checking against segment boundaries
first (I guess you want to, or you wouldn't have proposed starting both
segments at the same address), the data segment would have to be
exactly 64k (4G) in length. So you would gain the ability to detect
stack overruns, but loose the ability to chmem the program, trap on
dereferencing pointers that point outside your address space (because
there is no `outside' anymore, and on the 386, every program could even
access all memory. Of course, on the 386, you could use paging and map
only those pages that belong to your process, but then you don't need
segments.

--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |