I'm not sure I follow. When you use unsafe features, you can defeat
most any intended invariant; that's what makes them unsafe, right?
Whether this particular example is ok depends on what you want
`unsafe-global` to mean. If you want it to correspond to external state
--- such as a filesystem or a remote process --- then it is implemented
ok. Otherwise, I agree that the implementation of `unsafe-global` is
bad.
If you count the behavior as bad, then you're right that fixing it up
means using similar unsafe functionality. Specifically, the
scheme_register_process_global() function (accessible only via
`ffi/unsafe`) helps to implement state that spans instantiations and
places.
At Tue, 29 Apr 2014 06:10:19 -0600, Jay McCarthy wrote:
If you look at this directory:
https://github.com/jeapostrophe/exp/tree/master/fffhase-attack
There's a short attack on the promise that different instantiations
of the same module across phases don't share a store.
Running without compiled version
rm -fr compiled
racket -t phase0.rkt --
static: unsafe-global was 0
static: safe-global was 0
dynamic: unsafe-global is 1
dynamic: safe-global is 0
Running with compiled version
raco make phase0.rkt
racket -t phase0.rkt --
static: unsafe-global was 0
static: safe-global was 0
dynamic: unsafe-global is 0
dynamic: safe-global is 0
Should we consider this fine because the effect is external (just
like touching a file) or should there be a generalization of the
racket/gui/base rule that the module can't be instantiated multiple
times?
A bit of a grep doesn't lead to any easy place where that is
implemented it seems like that feature can only be implemented
with a restricted form of the attack itself, so you can observe that
the instantiation already happened.
Jay
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
