opsfile.tgz
Jens Rieks
On Tuesday 23 March 2004 14:49, Gay, Jerry wrote:
> > - do we expect to have more then 32 different classes?
>
> i see 13 operator classes currently, though my tree may be out of date
I think we should limit the number of unique IDs available at runtime to 32.
We can assign the same number to several symbolic names (maybe even on demand,
at runtime). This way, one can at least query if a specific feature is
enabled.
We then have "meta groups", for example a single "math" group instead of
base_math and advanced_math; I think it is harmless if enabling one feature
does also enable another (related) feature.
A fine graded OP classification can be a win, but it is not necessary to be
able to play around with 100000 different hints _at runtime_.
If hints can be freely grouped (at compiletime), everyone should be able to
get a parrot that fulfils even very specific needs. Hints should IMO only be
used to control parrot's core OPs. Extensions (i.e. special RE ops) can be
controlled by restrictions at loadtime.
> > A perl script that scans ops-files for opcode classes and spits out:
> >
> > a) a pod with opcode classes headings and the list of opcodes that
> > belong to that class (at best created from a template, which has some
> > more explanation to that stuff)
>
> the attached tarfile contains a script (tools/docs/opslist.pl) should
> generate a file, docs/ops/opslist.pod, with the above information
I belive Leo meant the hint classes, base_core and base_network for example.
> > b) a C include file that defines bitmask enums for the
> > classes plus some
> > common shortcuts comming from a config file. These enums
> > should then be
> > scanned during Configure and provide a user visible PASM in
> > runtime/parrot/include.
> > If we have more then 32 classes, we'll use a ParrotSet PMC
> > (which will
> > be handy anyway)
>
> i'm not sure where to get the info i need to do this.
lib/Parrot/OpLib/core.pm
> hope the attached script helps.
The list looks okay, maybe it can be kept as an additional section.
Another section should show all hint groups and the OPs that belong to this
list. A simple list is included in my previous mail from yesterday.
> > leo
>
> --jerry
jens
Dan Sugalski
>On Tuesday 23 March 2004 14:49, Gay, Jerry wrote:
>> > - do we expect to have more then 32 different classes?
>>
>> i see 13 operator classes currently, though my tree may be out of date
>I think we should limit the number of unique IDs available at runtime to 32.
We ought to limit it to 0, actually. :) These classifications are all
compile-time things as they affect the code the preprocessor emits. I
don't think there's much use for the meta-information to be there at
runtime and I certainly don't think it should be *used* at runtime...
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
>>I think we should limit the number of unique IDs available at runtime to 32.
> We ought to limit it to 0, actually. :) These classifications are all
> compile-time things as they affect the code the preprocessor emits.
And how do you handle PBCs then?
leo
Jens Rieks
> At 3:43 PM +0100 3/23/04, Jens Rieks wrote:
> >On Tuesday 23 March 2004 14:49, Gay, Jerry wrote:
> >> > - do we expect to have more then 32 different classes?
> >>
> >> i see 13 operator classes currently, though my tree may be out of date
> >
> >I think we should limit the number of unique IDs available at runtime to
> > 32.
>
> We ought to limit it to 0, actually. :) These classifications are all
> compile-time things as they affect the code the preprocessor emits. I
> don't think there's much use for the meta-information to be there at
> runtime and I certainly don't think it should be *used* at runtime...
modifications at runtime. They should be declared at compiletime, and I think
they can be very useful to maintain system security when running untrusted
code.
It can be implemented as per-interpreter (or eventually runloop?) hints, to be
able to disallow things like creating new/altering existing classes, loading
of bytecode, disabling IO OPs and such things.
A "query_hint" OP can be used to check at runtime if file access or network
usage is permitted, for example.
For security reasons, it should only be possible to test whether a feature is
available, and to disable features. Either completely (until the interpreter
exists) or for the current scope (handled like warnings?).
It can be implemented as an (32bit) integer in the interpreter structure. Only
a bit test against a predefined mask is needed to check if an instruction is
allowed in a given context. "if( interpreter->hints & Parrot_hint_base_io )"
The code for it can be spread out automatically for OPs belonging to a
specific hints group.
It is not necessary for base_core OPs, since it makes no sense to disable
them. Other OPs (i.e. open) are doing rather complex things, a single bit
test is not going to slow them down very much.
Maybe its even enough to implement it for the slow/secure core.
I belive that this will help to maintain the system's security when running
untrusted code.
jens
Dan Sugalski
No differently.
I've half a reply to all this--I'll fire it off shortly.