[squeak-dev] Mirror primitives

Eliot Miranda eliot.miranda at gmail.com
Mon Sep 7 21:05:15 UTC 2009


On Mon, Sep 7, 2009 at 1:47 PM, Colin Putney<cputney at wiresong.ca> wrote:
>
> On 7-Sep-09, at 1:10 PM, Eliot Miranda wrote:
>
>> 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.
>
> One year at StS I had a discussion with Travis about Trippy. He mentioned to
> me that they had planned to use the mirror primitives for Trippy, but
> ultimately found that it was better to do something similar to what you
> describe above: compile a method that answers an instvar then execute with
> the object as the receiver using the inverse of #withArgs:evaluate:
> something like #valueWithReciever:args: on CompiledMethod. This seems like a
> powerful and flexible approach to me. You can do anything the object its
> self can do with its internal state, but completely bypass message dispatch.
> Best of all there's only one primitive required.

In Squeak valueWithReciever:args: is built upon withArgs:evaluate:.
See my other posts on the holes that valueWithReciever:args: open up.
The VW debugger still uses the mirror primitives so I don't see the
engineering effort to add the alternative path was worth it.

> Admittedly a debugger involves a bit more than an inspector, but the
> technique would seem to be applicable. Is there some reason that this
> combined with traditional simulation wouldn't work well?

In principle, no.  Provided one caches the methods, then there's no
performance issue.  But is it any better?  There's no difference in
security.  The fact that one can implement things either way
demonstrates this.  The security issue is whether the system can work
correctly without facilities analogous to the mirror primitives.  The
implementation of Process>>terminate means that there isn't, because
it uses the execution simulation machinery, and for correctness the
execution simulation machinery needs mechanisms isomorphic to the
mirror primitives, no matter how they are implemented.

I think an implementation which makes it easy to strip out the mirror
primitives when deploying is attractive.  The mirror primitives are
simple to use and understand.  So the thing to focus on is process
termination.  Remove execution simulation from that path and the
system is more secure (if that's important to you).  Keep incorrect
execution simulation in process termination and the system functions
without the mirror primitive hole (but with plenty of others) but is
incorrect w.r.t. processes on encapsulators (if that's important to
you).

>
> Colin
>
>



More information about the Squeak-dev mailing list