[Python-Dev] Defending against stack overflow (was Sandboxing Python) (original) (raw)

Mark Shannon mark at hotpy.org
Sun Mar 4 13🔞42 CET 2012

Having a look at the "crashers" in Lib/test/crashers it seems to me that they fall into four groups.

  1. Unsafe gc functions like getreferrers()

  2. Stack overflows.

  3. "Normal" bugs that can be fixed on a case-by-case basis (like borrowed_ref_1.py and borrowed_ref_2.py)

  4. Things that don't crash CPython anymore and should be moved.

  5. can be dealt with by removing the offending function(s),

  6. by fixing the problem directly.

  7. no need to fix, just move :)

So, how to handle stack overflows (of the C stack)? To prevent a stack overflow an exception must be raised before the VM runs out C stack. To do this we need 2 pieces of info: a) How much stack we've used b) How much stack is available.

(a) can be easily, if not strictly portably, determined by taking the address of a local variable. (b) is tougher and is almost certainly OS dependent, but a conservative estimate is easy to do.

A different approach is to separate the Python stack from the C stack, like stackless. This is a much more elegant approach, but is also a lot more work.

I think it is a reasonable aim for 3.3 that Lib/test/crashers should be empty.

Cheers, Mark.

More information about the Python-Dev mailing list