Re: checking arbitrary bytecode for potential crashes
Dima Tisnek <[email protected]> Wed, 1 Oct 2014 08:19:14 +0200
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <CAGGBzXJKcuTftBb0fM_rvt9nT2=2tKKJfmxz8PAokYwyQM=F1g@mail.gmail.com> |
Makes sense. Do you think it's realistic to map arbitrary bytecode to opcode or ast api and let bytecodeassembler recreate said bytecode with some validation, or is that just not possible in general case? d. On 1 October 2014 02:16, PJ Eby <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> wrote: > On Tue, Sep 30, 2014 at 4:57 AM, Dima Tisnek <[email protected]> wrote: >> Hi all, >> >> BytecodeAssembler mentions that "It should now be virtually impossible >> to accidentally generate bytecode that can crash the interpreter. (If >> you find a way, let me know!)" >> >> How do I invoke this validation? >> >> Here's a simplest example after ned and lvh: >> >> code_obj = peak.util.assembler.code(0, 0, 1, 0, "KABOOM", (), (), (), >> "gooo", "goo", 1, "l") > > That doesn't look accidental to me. That looks like you did it on purpose. ;-) > > To elaborate: > > * There is no validation for raw bytecode -- it's Bytecode*Assembler*, > not RawBytecodeVerifier ;-) > * It's simple stack-level validation and dead-code prevention, not > security validation > * As it says, it's intended to prevent *accidental* crashing code > caused by bugs in your bytecode generation process using the opcode or > AST APIs. > > ;-)