The open opcode

Allison Randal allison at
Fri Apr 23 08:25:22 UTC 2010

On 4/23/10 2:03 AM, Jonathan Leto wrote:
> I have attached a small patch that allows me to secure PL/Parrot
> against the open opcode. It comes at the cost of a single
> Parrot_PMC_typenum(interp,"FileHandle") lookup, per call of the open
> opcode, which is an extremely tiny performance hit and unbreaks
> encapsulation.

I'm okay with this patch, as long as it's temporary (a non-specific 
time-frame something like "we replace it before 2.9").

On what to replace it with:

- That direct usage of the FileHandle typeid already should have been 
wrapped in a call to Parrot_get_ctx_HLL_type.

- We shouldn't be ASSERTing based on typenum there anyway, to allow for 
HLL mapping of FileHandle.

- If masking entire core PMCs becomes a standard security strategy we 
might want to consider a feature similar to HLL mapping in the security 
layer, that cleanly substitutes the custom PMC for the core PMC.

- I'd like to see security features built into FileHandle (jonathan and 
I have talked about this on IRC), altering behavior based on an 
interpreter or system-wide security level setting.

- Selective enabling/disabling of opcodes is still on the menu. I'm not 
as certain about selective overriding of opcodes. It's not possible now, 
but might be with Lorito.


More information about the parrot-dev mailing list