The open opcode

[Allison Randal]

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.

Allison