Safe Mode for Parrot -- Need a volunteer
Dan Sugalski
While there's a *lot* to ultimately do, the initial part, a paranoid set
of ops and a runloop that understands it, is relatively simple. What we
need is someone to thump the code that generates the core_ops.c files (and
their kindred) to getnerate an alternate set of runloops and op functions.
These functions, to start, are relatively simple. All that needs to be
done is for there to be a preamble emitted for each op function that does
simple validation of the parameters. That means the register number must
be between 0 and 31, and that any P or S register that is an 'in'
parameter must be non-NULL.
Anyone care to take a shot?
Dan
Leopold Toetsch
> Dan --
> Here's a first version that works with the regular core.
> You have to explicitly define PARANOID, or the added code
> won't get compiled.
It IMHO should be a separate run core, which can be switched to,
whenever safe execution is desired. Then we want to turn off some
opcodes especially these, which would allow to escape from the safe
core. Generally we need a classification of opcodes, so that we can
disable e.g. all IO cops.
WRT implementation: Putting the register range check in each opcode
function just blows the core size. Its much simpler to have one central
place to inspect the program code.
I'd use the switched core (or better a safe switched core derived from
it) as the base. Its a predereferenced core, so during safe prederef
some of these checks can be done in advance.
While its seems legitimate to check P and S registers for
NULL, its suboptimal to generally disallow NULL registers. NULL PRegs
are in use e.g. for C<dlfunc> and if the code allows execution of dlfunc
(probably not but ...) a NULL value for the dl-handle is valid.
And finally composite keys may have registers too.
leo
Gregor N. Purdy
Thanks for taking the time to review and comment.
> > Here's a first version that works with the regular core.
>
> > You have to explicitly define PARANOID, or the added code
> > won't get compiled.
>
> It IMHO should be a separate run core, which can be switched to,
> whenever safe execution is desired. Then we want to turn off some
> opcodes especially these, which would allow to escape from the safe
> core. Generally we need a classification of opcodes, so that we can
> disable e.g. all IO cops.
The reason I wrapped the new code in an #ifdef PARANOID is
precisely so that you could use cc -o to override the object
file name and build two different .o files (one paranoid and
one not) from a single source file. Of course, there are probably
other things that need to be done, but I didn't want to make
2 * N new .c files to get paranoid versions of the N core .c
files now.
> WRT implementation: Putting the register range check in each opcode
> function just blows the core size. Its much simpler to have one central
> place to inspect the program code.
> I'd use the switched core (or better a safe switched core derived from
> it) as the base. Its a predereferenced core, so during safe prederef
> some of these checks can be done in advance.
I thought about prederef a bit right before submitting this, and
I think the prederef code path is a great place to do the checks.
In fact, I'm wondering if the prederef process shouldn't just do
the paranoid checks always, since the point of its process is to
make one slightly slower pass through things so that subsequent
passes can get a speed boost. Maybe it won't be too much of a hit
to leave PARANOID as a built-in part of it always.
> While its seems legitimate to check P and S registers for
> NULL, its suboptimal to generally disallow NULL registers. NULL PRegs
> are in use e.g. for C<dlfunc> and if the code allows execution of dlfunc
> (probably not but ...) a NULL value for the dl-handle is valid.
Only 'in' S and P registers are being checked for NULLness.
I looked at dlfunc, and I think the right code is being
generated for PARANOID. Maybe you could post a code snippet
to point out where it is wrong...
> And finally composite keys may have registers too.
I have to admit I don't know much about the way the keyed stuff
works. It appeared in Parrot after my big push of effort. I've
been wanting to integrate it into Jako as a way of learning how
it works, but alas my supply of tuits has been very low for
some time.
Regards,
-- Gregor
--
Gregor Purdy gre...@focusresearch.com
Focus Research, Inc. http://www.focusresearch.com/
Leopold Toetsch
> ..., but I didn't want to make
> 2 * N new .c files to get paranoid versions of the N core .c
> files now.
One safe core, built separately with its own Ops files ought to be
enough, IMHO.
> I thought about prederef a bit right before submitting this, and
> I think the prederef code path is a great place to do the checks.
Yep.
> In fact, I'm wondering if the prederef process shouldn't just do
> the paranoid checks always, since the point of its process is to
> make one slightly slower pass through things so that subsequent
> passes can get a speed boost. Maybe it won't be too much of a hit
> to leave PARANOID as a built-in part of it always.
I'd do simple checks always as register range ckecks. But more
complicated ones like decomposing keys and checking key register numbers
or constant table entries could be done only if the paranoid flag bit of
the prederef function is turned on.
>> While its seems legitimate to check P and S registers for
>> NULL, its suboptimal to generally disallow NULL registers. NULL PRegs
>> are in use e.g. for C<dlfunc> and if the code allows execution of dlfunc
>> (probably not but ...) a NULL value for the dl-handle is valid.
> Only 'in' S and P registers are being checked for NULLness.
> I looked at dlfunc, and I think the right code is being
> generated for PARANOID. Maybe you could post a code snippet
> to point out where it is wrong...
e.g. from src/parrot/languages/imcc/t/syn/pcc.t
.sym pmc NULL
null NULL
dlfunc FABS, NULL, "fabs", "dd"
Passing a NULL handle to dlfunc aka dlsym gets you functions of the main
program.
>> And finally composite keys may have registers too.
> I have to admit I don't know much about the way the keyed stuff
> works. It appeared in Parrot after my big push of effort. I've
> been wanting to integrate it into Jako as a way of learning how
> it works, but alas my supply of tuits has been very low for
> some time.
jit.c:263 ff has an example of getting registers out of keys.
> Regards,
> -- Gregor
leo