RE: Bytecode safety

[Dan Sugalski]

At 06:44 PM 9/18/2001 -0700, Hong Zhang wrote:
> > Proposed: Parrot should never crash due to malformed bytecode.  When
> > choosing between execution speed and bytecode safety, safety should
> > always win.  Careful op design and possibly a validation pass before
> > execution will hopefully keep the speed penalty to a minimum.
>
>We can use similar model as Java bytecode. Because of poor design, the
>Java bytecode requires exponential algorithm to verify the bytecode,
>mainly caused by weak-typing on local variables (where all other parts
>of Java runtime are strongly typed), and the notorious jsr/ret bytecode.
>We should avoid the same kind of mistakes. The bytecode verification
>should be about O(n * ln(n)).

Given how weakly typed so much of Perl (and thus Parrot) is, I'm not sure 
that there's much we can do to verify externally. The best I can think of 
is to have the dangerous ops validate their parameters and the oploop do 
resource checks as appropriate. :(

I may, however, be suffering from a lack of imagination. That'd be OK.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: Bytecode safety

[Hong Zhang]

> Proposed: Parrot should never crash due to malformed bytecode.  When
> choosing between execution speed and bytecode safety, safety should
> always win.  Careful op design and possibly a validation pass before
> execution will hopefully keep the speed penalty to a minimum.

We can use similar model as Java bytecode. Because of poor design, the
Java bytecode requires exponential algorithm to verify the bytecode,
mainly caused by weak-typing on local variables (where all other parts
of Java runtime are strongly typed), and the notorious jsr/ret bytecode.
We should avoid the same kind of mistakes. The bytecode verification
should be about O(n * ln(n)).

Hong

Re: Bytecode safety

[Dan Sugalski]

At 02:37 PM 9/18/2001 -0700, Damien Neil wrote:
>Proposed: Parrot should never crash due to malformed bytecode.  When
>choosing between execution speed and bytecode safety, safety should
>always win.  Careful op design and possibly a validation pass before
>execution will hopefully keep the speed penalty to a minimum.
>
>Yes, no?

Yes and no.

The default dispatch loop shouldn't check. The Safe dispatch loop (note the 
caps there... :) should check.

Checking is more than just a plain safety issue. There are resource checks, 
different jump op functions, and a variety of disabled or paranoid things 
in there.

It's a non-trivial problem, but it is one that we should, and must, address 
at some point. I hadn't planned on doing it so soon, but if someone's so 
inclined, that'd be great. :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Bytecode safety

[Russ Allbery]

Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes:

> I would vote no.  HOWEVER, I would think that the user should have the
> option to turn on checking for malformed bytecode (i.e. Safe mode).  In
> the default case, I think the bytecode should be assumed well formed and
> no extra checking be performed.

Something akin to gcc's --enable-checking strikes me as a really good
idea.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Bytecode safety

[Sam Tregar]

On Tue, 18 Sep 2001, Damien Neil wrote:

> Proposed: Parrot should never crash due to malformed bytecode.  When
> choosing between execution speed and bytecode safety, safety should
> always win.

I don't see this as a safety issue.  There's nothing unsafe about
crashing.  It's just not as pretty as putting up a big ol' "YOUR BYTECODE
IS SNOOKERED" message.  Having that message is not worth even a 1%
degradation in runtime speed.

> Careful op design and possibly a validation pass before
> execution will hopefully keep the speed penalty to a minimum.

Sounds great, but make it a separate program that gets run optionally with
the default being to not run it.  Validating variable-length instructions
takes non-trival time and having it outside the normal execution path will
allow to indulge in whatever costly-code analysis you desire.

-sam

Re: Bytecode safety

[Damien Neil]

On Tue, Sep 18, 2001 at 10:40:30PM +0100, Simon Cozens wrote:
> On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote:
> > Proposed: Parrot should never crash due to malformed bytecode.
> 
> Haven't we done this argument? :)

Sort of, while talking about other things.  I wanted to drag it out to
stand on its own. :>

   - Damien

Re: Bytecode safety

[Simon Cozens]

On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote:
> Proposed: Parrot should never crash due to malformed bytecode.

Haven't we done this argument? :)

I'd vote no, FWIW.

-- 
Dames lie about anything - just for practice. -Raymond Chandler

RE: Bytecode safety

[Gibbs Tanton - tgibbs]

I would vote no.  HOWEVER, I would think that the user should have the
option to turn on checking for malformed bytecode (i.e. Safe mode).  In the
default case, I think the bytecode should be assumed well formed and no
extra checking be performed.

-Original Message-
From: Damien Neil
To: [EMAIL PROTECTED]
Sent: 9/18/2001 4:37 PM
Subject: Bytecode safety

Proposed: Parrot should never crash due to malformed bytecode.  When
choosing between execution speed and bytecode safety, safety should
always win.  Careful op design and possibly a validation pass before
execution will hopefully keep the speed penalty to a minimum.

Yes, no?

   - Damien

Bytecode safety

[Damien Neil]

Proposed: Parrot should never crash due to malformed bytecode.  When
choosing between execution speed and bytecode safety, safety should
always win.  Careful op design and possibly a validation pass before
execution will hopefully keep the speed penalty to a minimum.

Yes, no?

   - Damien