On Wed, Dec 16, 2009 at 11:24 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 16.12.2009, at 18:43, Eliot Miranda wrote:
>
>
>
> On Wed, Dec 16, 2009 at 2:21 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>
>> On 16.12.2009, at 03:11, David T. Lewis wrote:
>> >
>> > On Tue, Dec 15, 2009 at 08:35:55PM +0100, Levente Uzonyi wrote:
>> >>
>> >> We should definitely keep the tests. After a bit of googling I found
>> >> Eliot's email which didn't get much attention:
>> >>
>> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-September/003161.html
>> >> This explains everything about mirror primitives. I wonder why these
>> >> changes aren't integrated into VMMaker. (Note that ContextPart >>
>> >> #objectClass: is missing from the attached source, I added an
>> >> implementation to the trunk). I marked the failing tests as expected
>> >> failures.
>> >>
>> >
>> > Thanks for the pointer. I somehow completely overlooked this posting
>> > on the vm-dev list. I opened a Mantis issue for "Add Mirror Primitives
>> > to the VM" to track it.
>> >
>> >  http://bugs.squeak.org/view.php?id=7429
>> >
>> > Dave
>>
>>
>> IIUC these new primitives break object encapsulation, which is fundamental
>> change to the VM.
>>
>> Do we care?
>>
>
> Very much so.  The implementation of the execution simulation machinery
> (the debugger) is incorrect without them.  For example, if you step through
> code on an encapsulator using the existing machinery every time an attempt
> is made to access an instance variable the message instVarAt: will get sent
> to the encapsulator, which will catch it in its doesNotUnderstand: method
> and answer an entirely erroneous value.
>
> The execution simulation machinery *must not* send messages to access state
> for correctness.  The VM does not send messages to access state; the
> execution simulation machinery must mimic the VM.
>
> This is not much worse a violation of encapsulation than instVarAt: and
> instVarAt:put:.
>
>
> It is fundamentally different, because those methods actually have to be
> implemented in the object. My object can intercept #instVarAt: but not the
> mirror prims.
>
>  Yes, the facilities can be misused, but so can thisContext, instVarAt: and
> much other reflective machinery.  In practice they are not misused and their
> power by far repays their danger.
>
> On the other hand, not being able to debug exotic code is a serious
> problem.  This is often the kind of code one most needs help with.
>
>
> Agreed, the facility is useful in debugging exotic code. Most code isn't
> exotic though. So my question stands if we want to compromise the whole
> system for these exotic situations. Since the facility is useful it might be
> okay to include if we can turn it off.
>

There is a better way, but it requires rewriting the primitives.  As a quick
hack I simply used primitiveInstVarAt et al and made them pop the right
number of arguments instead of assuming what their argumentCount was.  But
if the mirror primitives were implemented in MethodContext they could fail
if the object being operated on wasn't the receiver slot.  [Alternatively we
could write the primitives to take the object to be operated on from the
receiver slot, but that's trickier].  That way only a context could meddle
with its receiver, which is no material change, given that that;s what
contexts can do now.

Is that acceptable?

>
>
>> If so, do we still want them?
>>
>> If yes, should there be a way to disable them, similarly to how we can
>> disable file access?
>>
>
> In the short/medium term, unload the debugger, the compiler, and any other
> reflective machinery.
>
>
> Won't help, since with access to that primitive my object can do pretty
> much anything.
>
> In the bright rosy future concoct a convincing story around capabilities or
> mirrors which carefully modulate use of these facilities so they can't be
> misused.
>
>
> That's exactly my point - I don't see how you could do a safe
> capability-based system with those primitives that can work around any
> encapsulation and hence can circumvent any capabilities.
>

Bert,  how do you stop me doing yourObject class compile: 'trojanHorse:
index <primitive: 73> ^nil' ?  Being able to implement instVarAt: is no
protection.  You need to do a lot more work than that.


> - Bert -
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091216/36be1042/attachment.htm