_FAST opcodes do no range checking

[larryhastings]

BPO	17190
Nosy	@rhettinger, @larryhastings
Files	crashy2.py: Script demonstrating crashing Python with hand-written bytecode

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-02-12.07:12:27.415>
created_at = <Date 2013-02-12.06:14:34.662>
labels = ['interpreter-core', 'invalid', 'type-crash']
title = '_FAST opcodes do no range checking'
updated_at = <Date 2013-02-12.08:23:37.186>
user = 'https://github.com/larryhastings'

bugs.python.org fields:

activity = <Date 2013-02-12.08:23:37.186>
actor = 'larry'
assignee = 'none'
closed = True
closed_date = <Date 2013-02-12.07:12:27.415>
closer = 'rhettinger'
components = ['Interpreter Core']
creation = <Date 2013-02-12.06:14:34.662>
creator = 'larry'
dependencies = []
files = ['29046']
hgrepos = []
issue_num = 17190
keywords = []
message_count = 3.0
messages = ['181944', '181945', '181948']
nosy_count = 2.0
nosy_names = ['rhettinger', 'larry']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue17190'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

[larryhastings]

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.

[rhettinger]

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?

[larryhastings]

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.