[squeak-dev] Mirror primitives

Eliot Miranda eliot.miranda at gmail.com
Mon Sep 7 20:46:09 UTC 2009


On Mon, Sep 7, 2009 at 1:29 PM, Igor Stasenko<siguctua at gmail.com> wrote:
> >From VM's perspective , all object are just a state holders, with slots and
> determined size(s).
> In language environment, however, the objects are treated as a
> black-boxes to which you can
> send the messages only.
> The debugger is staying somewhere in the middle, i.e. it should know
> how to connect these two realms
> in order to simulate VM-specific behavior when you stepping over the code.
> So, for the means of debugging i tend to agree that mirror prims will
> be quite useful.
> But same as Bert i don't want to see these prims abused by people who
> bypassing the 'black-box' paradigm
> by using them, so we ending up with a 'static-type-oriented' C-like
> programming instead of object oriented one.

I understand, but the argument is a bit further along than that.  The
question is whether the addition of the mirror primitives makes the
situation significantly worse than it is already with the presence of
instVarAt:put: primitiveChangeClassTo: become: and the compiler.  I
can easily subvert any encapsulation by a class that doesn't inherit
from Object or ProtoObject and doesn't implement instVarAt:put: by
using reflection to enumerate over all classes, and adding the
instVarAt:put: method to all root classes' method dictionaries under a
selector of my choosing.  I can construct a context activation on some
object with a method of my construction and set it running.  I don't
even have to have the compiler for either of these exploits.  The open
meta system is simply not secure.

I argue that therefore adding the mirror primitives does not
materially make the situation any worse than it already is, but does
give one an accurate debugger, and accurate process termination.  I
argue that the mirror primitives are in some sense isomorphic in their
insecurity to the existing meta facilities (such as open access to
thisContext), but that in practice the openness of the meta-system has
not presented a security problem; images and processes are still
sealed, and secure applications which do not allow the import or
execution of arbitrary code can still be deployed even though they
contain apparently insecure code because they do not provide a path
such that externally that unsafe code can be activated, and because
internally those applications do not misuse the
encapsulation-violating facilities such as instVarAt:put:.

I argue that in practice encapsulation is a design convention that
allows one to reason more effectively about complex systems, but that
it is not a hard-and-fast rule, and that breaking encapsulation in
certain stereotypical situations is common and extremely useful, for
example in reconstructing or transporting objects that have been
externalised on some stream.

>
> 2009/9/7 Eliot Miranda <eliot.miranda at gmail.com>:
>> On Mon, Sep 7, 2009 at 12:34 PM, Bert Freudenberg<bert at freudenbergs.de> wrote:
>>>
>>> On 07.09.2009, at 21:29, Eliot Miranda wrote:
>>>
>>>> On Mon, Sep 7, 2009 at 12:19 PM, Bert Freudenberg<bert at freudenbergs.de>
>>>> wrote:
>>>>>
>>>>> On 07.09.2009, at 20:56, Eliot Miranda wrote:
>>>>>>
>>>>>> I have fixes for this integrated in Qwaq.  This is work I did for
>>>>>> VisualWorks a while back.  The idea is to add a set of mirror
>>>>>> primitives, so called because they do reflection, to ContextPart.
>>>>>> These primitives implement the basic operations of the object model
>>>>>> needed for execution simulation, fetching an object's class, accessing
>>>>>> its named and indexed instance variables, and the number of indexed
>>>>>> instance variables, sending a message, but they take the object
>>>>>> operated on as a parameter and so do function without sending messages
>>>>>> to that object.
>>>>>
>>>>> Wouldn't that break encapsulation in a way we never had to before?
>>>>
>>>> If one dared use those primitives for anything other than simulating
>>>> the VM then I suppose they're a little worse than instVarAt:put: and
>>>> basicAt:put:, but not so much.
>>>
>>> These are fundamentally different. #instVarAt:put: and basicAt:put: are
>>> regular methods that an object itself implements to give others access to
>>> its internal state. It can very well chose not to.
>>
>> Yes, but they are implemented in Object and potentially defeat
>> encapsulation on every object in the system that inherits from it
>> (which is almost all).  In practice this isn't an issue because they
>> are not abused.  Its the same with the mirror primitives.  So while it
>> appears the sky can fall in a new way it doesn't.
>>
>>>
>>>>  I think it is much more dangerous to
>>>> have a debugger that appears to be correct but breaks one's code in
>>>> ways that are horribly difficult to understand.
>>>>
>>>> Note that both Self and Newspeak (and VisualWorks) take the mirror
>>>> primitive approach.  But there is certainly a security issue and one
>>>> wants to medate access to the mirror primitives carefully.
>>>
>>>
>>> Alas we have no way for restricting access in Squeak.
>>
>> I can imagine a way using withArgs:evaluate:.  Compile the methods,
>> save them in class variables of ContextPart and access them through a
>> checking interface that only allows their execution in the context of
>> the debugger.  But I still think this is overkill.  What, in Squeak,
>> is to stop one compiling a method on ProtoObject and using it to
>> subvert encapsulation on all objects?  Nothing.  So the issue of
>> security is not made any worse by the introduction of the mirror
>> primitives, but the debugger is enhanced significantly.  So for me
>> they're a clear win.
>>
>>
>>>
>>> Anyway, these primitives are useful for debugging indeed. How about
>>> disabling them in production mode?
>>
>> Alas the process termination code uses execution simulation to
>> terminate suspended processes and that means using the mirror
>> primitives to safely terminate processes.  The current non-mirror
>> implementation could conceivably screw up terminating processes
>> executing code on encapsulators.
>>
>> I think a better way is to propose a security mechanism that prevents
>> their abuse.  Any ideas?
>>
>>>
>>> - Bert -
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>



More information about the Squeak-dev mailing list