Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

API to tell which opcode group an opcode is in #650

Open
leto opened this Issue · 4 comments

2 participants

@leto
Owner

I am currently hacking on PL/Parrot and one of the very important features that we need is disallowing certain operations, most notably file I/O. The motivation for this is that you do not want a stored procedure written in PIR to be able to modify the database via disk operations.

I talked with chromatic in #parrot about needing some security subsystem features and he agreed that we need an API for telling if an opcode is in a particular opcode group. This is talked about in PDD18 if you want to get the full background.

For instance, take the open opcode:

inline op open(out PMC, in STR, in STR) :filesys_open {
/* etc... */
}

It is defined to be in the "filesys_open" opcode group. Currently there is no way to tell if a certain opcode is in a given group. The information does not seem to make it into op_info_t, but it is in lib/Parrot/OpLib/core.pm . I propose a public C API that will consist of at least these three functions:

Parrot_sec_opcode_is_in_group(string opcode_name, string group_name)

This function would take an opcode name and opcode group name as argument and return true if the opcode is in the group, false otherwise.

Parrot_sec_opcodes_in_group(string opcode_group)

This function takes a string argument of an opcode group name and returns a ResizableStringArray containing all opcodes in that group.

Parrot_sec_groups_containing_opcode(string opcode_name)

This function takes a string argument of an opcode name and returns a ResizableStringArray listing all groups that contain the given opcode name.

Once an API in C is available to accomplish these things, then it should be straight forward to access this information from PIR.

Originally http://trac.parrot.org/parrot/ticket/1500

@Whiteknight

Is a C API what we really want most here, or would methods on the Opcode and OpLib PMCs suffice? That is, is the ultimate goal to have this information available from PIR, or do we really want it available at the C level? Both?

@leto
Owner

Well, I originally wanted the API to be from C, so that embedding applications could access it, but it seems that if we can do it all from PIR, that would be sufficient, since a C app could just load the appropriate PIR/PBC that does this stuff.

@Whiteknight

Looking at the generated opcode source, I don't see that this group information is kept around. The open opcode isn't core anymore, but even in the generated C code of the dynoplib we don't seem to keep that information available anywhere. I'm not really sure how we want to try to expose the information if it's not currently being kept.

Also, are there a fixed number of groups so we could do something like a bitfield, or are group names arbitrary and would need to be kept around in strings?

@leto
Owner

Currently the plan is strings, but a bitfield could be done easily

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.