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

Open
leto opened this Issue Mar 6, 2010 · 4 comments

Comments

Projects
None yet
2 participants
Owner

leto commented Mar 6, 2010

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

Contributor

Whiteknight commented Aug 23, 2011

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?

Owner

leto commented Aug 23, 2011

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.

Contributor

Whiteknight commented Oct 24, 2011

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?

Owner

leto commented Feb 1, 2012

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