Re: Arbitrary Sandbox

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 20 Feb 2012 18:27:10 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 18 Feb 2012 13:55:48 -0500, Robert A Duff wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> I wonder what kind of architecture could require a safe implementation of
>>>> Ada, e.g. when private parts of packages and protected objects would be
>>>> mapped onto the memory physically inaccessible from public contexts.
>>> 
>>> The kind of architecture that is overly complicated
>>> and grossly inefficient.  Imagine a private type with
>>> discriminants.  The discriminant of each object is visible
>>> to clients; other components are not.  Or imagine a private
>>> extension of a (visible) record extension.  What about the
>>> fact that some portion (not all) of a child package has
>>> visibility on the private part (but not the body) of the
>>> parent package?
>>> 
>>> Why do work at run time that can be done at compile time?
>>
>> Because it cannot (in presence of Unchecked_Conversion and similar stuff). 
> 
> If U_C etc. causes trouble, use Java.  Or use a subset of Ada that
> doesn't allow such features.  I really can't imagine a sensible way to
> use such features and check them at run time.

Of course there is. Do you remember the last time U_C crashed Windows or
Linux?

>>> Implementing things in hardware doesn't magically make
>>> them free.
>>
>> It makes them incomputable. In a secure environment you wanted certain 
>> things to become incomputable for non-trusted clients, e.g. reading user 
>> passwords.
> 
> Sure, but Ada's visibility features (private types and the like)
> are not designed for security.

Yes, but they could be a good start. (If there were any interest. No need
to tell that there is none)

> Use other means for that (like protection based on paging).

That is low-level and inherently based on pointers.

>>> Putting high-level support for higher-level languages in hardware
>>> has been tried a number of times, and it's always been a bad idea.
>>
>> Maybe so. But this is a different case, because memory protection and 
>> segmentation support is already there. Why no high-level language uses it?
> 
> 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.

That was my point. There is a disconnect in the designs of the hardware and
higher level languages. You said it must be so. I disagree. There is no
other reason for that than the dark ages we are living at. Nobody invests
anything in serious language, OS, hardware design.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de