[Python-Dev] Is core dump always a bug? Advice requested

Guido van Rossum guido at python.org
Tue May 11 10:12:00 EDT 2004


Greg:
> > > As long as it's possible to attempt to execute arbitrary strings
> > > as bytecode, I'd say ceval should be robust against this.
> > 
Guido:
> > This ought to be a long-term project then: write a bytecode verifier.
> > It's not a trivial task!

Greg:
> When I wrote that, I was assuming that ceval was already mostly robust
> in this respect, and that what was being reported was a new hole
> recently opened up.
> 
> But it appears I was gravely mistaken, and that ceval has been full of
> gaping holes from the beginning.
> 
> I'm disappointed to learn this, because I had always regarded it as an
> axiom that no Python-level code should be capable of crashing the
> interpreter, and if it can, this represents a bug. However, it seems
> this axiom has not been adhered to in the design of ceval.

No, the holes aren't in ceval.  The hole is the ability to create new
code objects from arbitrary arguments, which wasn't planned at all
when ceval was designed.  I was always reluctant to add this
capability, but finally allowed it, consiciously opening up the hole,
under pressure from various people who wanted to do bytecode level
hacking.

The responsibility to validate bytecode should really be in new.code()
(and probably in new.function, which requires the code to behave in
certain ways).

Note that while I like the general principle that Python code
shouldn't be able to cause segfaults, I don't think we should see that
property as a safety *guarantee*.  It's more a code-of-honor of the
Python implementation.  There are many violations of the principle,
mostly in platform-specific extensions (it is easy to crash Python
with certain win32 primitives, for example, and it seems unreasonable
to expect otherwise).

--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list