classification
Title: _FAST opcodes do no range checking
Type: crash Stage: needs patch
Components: Interpreter Core Versions: Python 3.2, Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: larry, rhettinger
Priority: normal Keywords:

Created on 2013-02-12 06:14 by larry, last changed 2013-02-12 08:23 by larry. This issue is now closed.

Files
File name Uploaded Description Edit
crashy2.py larry, 2013-02-12 06:14 Script demonstrating crashing Python with hand-written bytecode
Messages (3)
msg181944 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2013-02-12 06:14
The implementations for LOAD_FAST, STORE_FAST, and DELETE_FAST don't check that the index is <= the size of fastlocals.  So it's a snap to crash the interpreter with hand-written bytecode, by going past the end of the fastlocals array.  Kaboom!

Attached is a program that demonstrates a crash with each of LOAD_FAST, STORE_FAST, and DELETE_FAST.  These all crashed 2.7, 3.2, 3.3, and a recent trunk.  (Well, two exceptions: LOAD_FAST and DELETE_FAST didn't crash 3.2.  Given the behavior, my suspicion is not that 3.2 is hardened, just that there's something dopey with my thrown-together test.)

It could be that this is not an interesting bug, that policy suggests that anyone who can write their own bytecode is a Consenting Adult.  You tell me.
msg181945 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-02-12 07:12
> It could be that this is not an interesting bug,
> that policy suggests that anyone who can write their 
> own bytecode is a Consenting Adult.

Yes, that is correct on all counts.

Sorry, this is an *ancient* discussion, long ago put to bed.

Besides, did you really want to kill the performance of our fastest opcodes in everyone's code just to save a bytecode hacker from shooting him/herself in the foot?
msg181948 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2013-02-12 08:23
I'm not surprised it was discussed to death long ago.  And I can get behind wontfix.  But let me just say that

a) I think an uncrashable Python interpreter is a laudable goal, and steps we can take towards that should not be dismissed out of hand.

b) I doubt a range check would "kill" the performance of the _FAST operands.  It'd be one lookup/compare/branch each, and the branch predictor would always guess correctly.  But I admit I have not tested it.

c) Anyway we needn't do it at runtime.  We could just as easily scan over the opcodes in the code object constructor and do the range checking there.  If we only did the check when the constructor was called directly from Python, it should have no measurable performance impact, only a maintenance cost.

d) I expect all these points were brought up in the original discussion.  I'd like to read that--but I can't find it.  Any pointers would be appreciated.
History
Date User Action Args
2013-02-12 08:23:37larrysetmessages: + msg181948
2013-02-12 07:12:27rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg181945

resolution: not a bug
2013-02-12 06:14:34larrycreate