On Fri 19 Feb, Peter Crowther wrote:

> As already pointed out elsewhere, this is compile-time.  It can be bypassed
> by perform: and probably by other hacks like storing an association to the
> code elsewhere with another name.  I'm after a mechanism that can protect
> private methods against determined crackers within an image; in a multi-user
> game, you can't assume everyone with code access is friendly.  This will
> involve the VM.
Quick thought on how to do this... possibly dud, but it's early and I haven't
been latte'd yet.

There are some bits available in the method headers  (or at least there are if
you use my NewCompiledMethod images) and one or more could be used to flag a
method as private. The message sending code could check this flag and
subsequently test the current reciever against the putative reciever of the
message being sent. If they do not match, do something like #cannotReturn (or
better yet do a proper exception raising) and work out what to do next.
With several flags available, we could even consider reifying the several-
levels-of-privacy idea Carl mentioned.
The flag checking could conveniently be done in the cache loading routine and
if we took the opportunity to 'fudge' the apparent primitive index we could
essentially detect the private flag(s) at no cost in
[internalE|e]xecuteNewMethod. Simply detect a primtiveIndex of some ludicrously
high number. By ORRing the flag into theprimitiveIndex we can keep the 'real'
primitiveIndex if any is needed for the method.

tim

-- 
Life would be so much easier if we could just look at the source code.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>