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.231.202 with SMTP id ti10mr19322897pbc.5.1329859143037;
        Tue, 21 Feb 2012 13:19:03 -0800 (PST)
Path: 
 wr5ni52679pbc.0!nntp.google.com!news2.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: Arbitrary Sandbox
Date: Tue, 21 Feb 2012 16:19:02 -0500
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wcczkcbj35l.fsf@shell01.TheWorld.com>
References: <bfeb9869-9323-4ad5-bdf8-af20593734ef@q8g2000pbb.googlegroups.com>
 <2aaee0a4-e820-4a75-bbaf-d9d09c366d2c@f5g2000yqm.googlegroups.com>
 <4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com>
 <jh7739$9os$1@munin.nbi.dk>
 <203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com>
 <jhh6qr$9av$1@munin.nbi.dk>
 <e10bf38c-3c48-4fa4-bb0a-e61211aee90d@f30g2000yqh.googlegroups.com>
 <193cr8xol0ysi.14p4cp2yxnb0r$.dlg@40tude.net>
 <op.v9veuwe6ule2fv@douda-yannick>
 <1jleu301thnd3$.s23priwn3ajb$.dlg@40tude.net>
 <wccobswc6ob.fsf@shell01.TheWorld.com>
 <18o3vqsl9uy2$.a3m68cg8ysro.dlg@40tude.net>
 <wccvcn1nl0x.fsf@shell01.TheWorld.com>
 <1fkgdlidn0v80$.kjvkmk7y29vo$.dlg@40tude.net>
 <wccvcn06qve.fsf@shell01.TheWorld.com>
 <o3otz4m13lh3$.53heve9256ek.dlg@40tude.net>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
X-Trace: pcls6.std.com 1329859142 22882 192.74.137.71 (21 Feb 2012 21:19:02
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Tue, 21 Feb 2012 21:19:02 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:rrM2WLLAjvE6a5L1zOTBoibO79g=
Content-Type: text/plain; charset=us-ascii
Date: 2012-02-21T16:19:02-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Consider design of a container library in Ada, which cannot broken whatever
> the client does. I think it is possible to achieve with the corresponding
> modifications of the language and appropriate hardware support.

We have appropriate hardware support.  You can isolate that container in
its own process, and allow communication with it via (say) the
Distributed Systems Annex.  In the (unlikely) absence of compiler bugs,
OS bugs, hardware bugs, and bugs in the container itself, you can
ensure that client bugs (or malicious clients) don't break your
container.

That's inefficient, which was part of my claim:  If you allow things
like U_C of pointers, and rely on hardware to prevent problems,
that hardware (and related software support) is going to be
inefficient.

Or you can go the pure-Java route (no JNI).  Then in the absence
of compiler (etc.) bugs, you can ensure that client bugs won't
break your container.  But that's not a complete solution, because
you can't write (for example) the garbage collector in Java -- you
*need* to do unsafe things in a GC.  And implementing the GC in
hardware won't magically make it bug-free, nor efficient.

- Bob