[issue17190] _FAST opcodes do no range checking
Larry Hastings added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17190] _FAST opcodes do no range checking
New submission from Larry Hastings: 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. -- components: Interpreter Core files: crashy2.py messages: 181944 nosy: larry priority: normal severity: normal stage: needs patch status: open title: _FAST opcodes do no range checking type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file29046/crashy2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17190] _FAST opcodes do no range checking
Raymond Hettinger added the comment: 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? -- nosy: +rhettinger resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17190 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
