The open opcode

Jonathan Leto jaleto at
Thu Apr 22 19:59:35 UTC 2010


I have been playing with some code that allows me to intercept access
to the File and FileHandle PMC from PIR [0], which allows me to add
some security to those when accessed from PL/Parrot. But I currently
do not have a way to intercept calls to the "open" opcode. Defining a
subroutine called "open" in the global namespace does not seem to
override it.

Chromatic and I talked on IRC about a "security" runcore, which would
allow replacing opcodes. The point was brought up that if you have
something that allows replacing opcodes, then that itself causes
another security hole. But if, at the end of replacing the necessary
ops, you then replace the "op replacer", that hole is closed.

A "security" runcore is definitely a great idea, and will be necessary
for many advanced security features for Parrot, but if someone can
think of a simpler way to replace the "open" opcode at run-time, I am
all ears. Would it be possible to replace the "open" opcode with a
dynop? I think that would be the smallest possible feature that Parrot
could add to give PL/Parrot the filesystem security that it needs.

Would making the open opcode a dynop create a noticeable decrease in
performance? That is the only reason I can see that we would not want
to go that route.


[0] -

PS: Thanks to Austin++ for the idea about intercepting PMC's.

Jonathan "Duke" Leto
jonathan at

More information about the parrot-dev mailing list