The open opcode
allison at parrot.org
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
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