[PEAK] checking arbitrary bytecode for potential crashes
Dima Tisnek
dimaqq at gmail.com
Wed Oct 1 02:19:14 EDT 2014
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 at telecommunity.com> wrote:
> On Tue, Sep 30, 2014 at 4:57 AM, Dima Tisnek <dimaqq at gmail.com> 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.
>
> ;-)
More information about the PEAK
mailing list