Re: Arbitrary Sandbox

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcceht4o92a.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>> You mean "already there" in 386/pentium?  Languages don't use it because
>>> it's inefficient, and because whatever segmentation can do can be done
>>> better by some combination of software and paging.
>>
>> The only reason it is "inefficient" was because OSes didn't use it.
>
> And OSes didn't use it because it for the reasons I stated.  It's a
> cyclic thing -- I'm sure Intel could have made it faster if there
> was demand.
>
> But there's an inherent inefficiency in segmentation: the size of
> all your pointers doubles.  Or to look at it the other way around,
> for any given amount of address space, it's split inconveniently.
> With the amount of memory I can afford today, a 32-bit segment
> number plus a 32-bit offset wouldn't be enough (both too few
> segments and segment size too small).  64-bit seg num plus
> 64-bit offset?  OK, big enough, but inefficient.  64-bit flat
> address space: perfect!  ;-)

I disagree. The 48-bit segment pointers of the x86 are big enough for some 
time to come, with the possible exception of a handful of extreme image 
processing programs. I do agree that there will come a point when 32-bits is 
not enough, but it's still a few years off. (About all the memory I can 
afford is 8GB, and that's going to be partitioned amongst several programs, 
so I don't see having any bigger than 4GB objects in the near future.)

And I would be perfectly happy with a 16:48 scheme for a foreseeable 
future -- I doubt there will be many machines with more than 2**48 bytes of 
memory any time soon.

In any case, you don't want to use a *lot* of segments. You just want 
separate segments for the major divisions in your code (executable code, 
constants, data, heap perhaps).

>>... That is,
>> it was quite efficient on an 386 (the only big expense occurs when 
>> reloading
>> segment registers, and that was something that occurred very rarely in 
>> the
>> two-segment model we used).
>
> OK, I have no idea what two-segment model you used.  I was picturing
> some sort of one-heap-object-per-segment model, and that sort of
> thing, which some folks have advocated as a "solution" to the
> problem of indexing out of bounds in languages that don't
> require detection of that.

As you note later, our source language is Ada and checking for out-of-bounds 
index values isn't a problem. The problem I was trying to prevent was 
executing random data, usually after some part of the stack got clobbered, 
as well as preventing the modification of code by screwed up pointers. So we 
just kept the code and data completely separate in separate segments, with 
no execute permission on the data segment and no write permission on the 
code segment. The x86 has separate registers for this anyway, so there's 
almost no overhead. In addition, since most code only uses the offsets, you 
can't accidentally read code when you meant to get data.

>> As far as "software" and "paging" being able to do anything, this makes 
>> no
>> sense at all. Pages on the x86 architecture don't (or at least didn't 
>> until
>> fairly recently) have any memory permissions associated with them, so it 
>> was
>> impossible to use that to prevent executing data.
>
> They had read/write bits and user/supervisor bits (per page) as far
> back as 80386.  You're right that execute permission was a glaring
> omission.  And even that isn't such a big deal if you use languages
> that have array bounds checking -- like Ada (to bring this slightly
> back on topic!).  Note that a no-execute stack doesn't prevent
> security problems if you can overwrite return addresses -- you
> can make them point to snippets of legitimate (executable) code.

Actually, it is a *very* glaring omission. Marking data as no execute is 
critical to improving code quality (our compiler got a lot better when we 
could do that, in large part because I didn't have to spend anywhere near as 
much time tracking impossible to pinpoint bugs). And it also was free, which 
was important for our small company that couldn't spend 10K on a fancy 
hardware ICE.

I agree that this scheme can't eliminate all security problems, but it does 
eliminate all code *injection* problems: because the segments prevent 
executing anything that can be modified. So it is impossible to execute any 
new code. It's still possible to leverage a bug to execute code that already 
exists somewhere in the program, but that's a lot harder to do. (And using 
static linking to ensure that no vestiage of unused APIs exists in your 
executable would help even more -- another place were Windows got this 
wrong). I realize there has to be an API to allow executing code created on 
the fly (for JIT compilers, for one use), but since the vast majority of 
programs don't use it, it can be protected (and not even present in the 
code).

BTW, I'm well aware that security people have finally caught up with this, 
and are finally doing most of these things (along with some others) in 
recent OSes like Windows 7. The annoying thing is that we used segments to 
do all of the above in our 1990-era DOS Extender compilers, so why it took 
nearly 20 years for the world to catch up is beyond me.

> But if you allow me to forget about x86 misfeatures, I stand by my
> statement, "whatever segmentation can do can be done better by some
> combination of software and paging" -- assuming a well designed
> paging system.  And assuming well designed programming languages!

You can't much forget about x86 misfeatures, because it was pretty much all 
there was until very recently. Until ARM started getting used a lot, every 
other architecture was down there in the noise.

In any case, the problem with paging is it requires wasting lots of address 
space. I suppose if you are willing to waste 64-bits for pointers (I still 
find 32-bit pointers wasteful!), it doesn't really matter. (I, after all, 
find the waste of space caused by alignment distasteful; Janus/Ada will pack 
everything to the nearest byte if you let it.)

                                        Randy.