From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,af0c6ea85f3ed92d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.74.201 with SMTP id w9mr2145493pbv.0.1331125534853; Wed, 07 Mar 2012 05:05:34 -0800 (PST) Path: h9ni49728pbe.0!nntp.google.com!news1.google.com!news.glorb.com!solaris.cc.vt.edu!news.vt.edu!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Wed, 07 Mar 2012 08:05:33 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <2aaee0a4-e820-4a75-bbaf-d9d09c366d2c@f5g2000yqm.googlegroups.com> <4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com> <203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com> <193cr8xol0ysi.14p4cp2yxnb0r$.dlg@40tude.net> <1jleu301thnd3$.s23priwn3ajb$.dlg@40tude.net> <18o3vqsl9uy2$.a3m68cg8ysro.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1331125534 4018 192.74.137.71 (7 Mar 2012 13:05:34 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 7 Mar 2012 13:05:34 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:qVDgjC4Ff3ktdcwg7oST5U5u2J0= Content-Type: text/plain; charset=us-ascii Date: 2012-03-07T08:05:33-05:00 List-Id: "Randy Brukardt" 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! ;-) >... 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 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. 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! - Bob