"Tim Peters" <tim.one at comcast.net> wrote in message news:E1BNkbA-0003fY-8g at mail.python.org... > Verifying what, precisely? Some things can clearly be checked. For > examples, that all opcodes are defined, that no LOAD_CONST tries to index > beyond the actual length of co_consts, and that no jump tries to branch into > the middle of some multi-byte opcode sequence Violations of such > simple-to-check kinds of things are what cause segfaults most often when > handing the PVM nonsense bytes. Harder to do is flow-sensitive eval stack > simulation, to ensure that no path through the code can push more on the > eval stack than was allocated for it, and that there's enough stuff on the > stack at each point to satisfy each opcode that requires accessing the eval > stack. > > A subset of what the Java bytecode verifier does is quite doable: Since I opened this somewhat hidden hornet's nest, the (newby) author of the code that caused the offending crash has admitted on clp that the code he fed to new.code was standard ascii Python code, not bytecode. In other words, something that almost certainly looked like gibberish to ceval. The limited goal of usually rejecting such 'random' byte strings, if adopted, *should* be doable since such should have many errors and we only need to catch one, not all, to reject. Protecting against maliciously or otherwise modified compiler output is a whole different game. Too bad there is no system-independent way to 'catch' crashes and exit more gracefully than usually useless core dumps, blue screens of death, or whatever. Terry J. Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4