String and bytecode bounds bugs
Phil Hassey
| Denis , Here's some bugs that I haven't documented or added yet, but maybe you can try and reproduce them .. these are bugs I've mainly thought of, but not actually gotten working: - bytecode in strings is not secure, a string could be given a huge length that goes beyond the end of the bytecode and tinypy will go out of bounds to read the string - same as previous issue, except for defining new functions - bytecode that should still be active can be garbage collected if all the references to it are removed - class A(B): .. class B(A): .. will cause an infinite recursion. Should set up the lookup to throw an exception after 16 lookups or something. If you can figure out how to reproduce those, that would be great .. if not, tell me, and I'll try to work up some test cases showing you these issues. As for an implementation tip, I think the fix for all of these bugs is to make bytecode be strings. Right now bytecode is just a pointer. We need the code to use strings across the board. One tricky point is that many strings and functions are substrings of bytecode. So I think maybe garbage collection should have the ptr be to the full source string .. so the parent string won't get recycled until all the substrings are as well. Thanks! Phil |
Phil Hassey
| I think the best approach to solving this problem will be in several steps: 1 - create test cases that reproduce the various issues mentioned .. I'll be glad to review those test cases once you've got them "working" (working, as in, causing a segfault or something that shows the errors are real) 2 - Likely pass around bytecode in a string object. No need to create a new type. -Phil --- On Mon, 7/21/08, Phil Hassey <philh...@yahoo.com> wrote: |
Phil Hassey
| Another related bug that is part of this is out-of-bounds jumps. Right now invalid bytecode can jump a user to anywhere .. -Phil |
Denis Kasak
>
> I think the best approach to solving this problem will be in several steps:
>
> 1 - create test cases that reproduce the various issues mentioned .. I'll be
> glad to review those test cases once you've got them "working" (working, as
> in, causing a segfault or something that shows the errors are real)
Infinite recursion with circular inheritance test case:
class A:
pass
class B:
pass
setmeta(A, B)
setmeta(B, A)
foo = A()
print("OK")
I'm a bit unclear on how to test those various out-of-bounds bugs. I
thought it would be easy, but it's not so straightforward since it
leads to jumping out of the bytecode altogether (by the nature of the
bugs). Would something simplistic like this show the problem?
STRING : 1 0 100 "foobar"
EOF : 0 0 0
The reasoning being that this should raise an "out-of-bounds"
exception and print it if the problem is fixed and print nothing if
the problem still exists.
--
Denis Kasak
Phil Hassey
| Denis, Yep - I think what you've got there makes sense. And the 3 out of bounds cases are: - strings - functions - jumps - going to next instruction - but that instruction not being within bounds -Phil --- On Wed, 7/30/08, Denis Kasak <denis...@gmail.com> wrote: |
From: Denis Kasak <denis...@gmail.com> |
Denis Kasak
Here are the tests for those bugs you mentioned:
1) Infinite recursion with circular inheritance test case:
class A:
pass
class B:
pass
setmeta(A, B)
setmeta(B, A)
foo = A()
print("OK")
2) Out of bounds - functions
DEF : 0 0 100
REGS : 2 0 0
STRING : 1 0 3 "foo"
NAME : 1 0 0
PASS : 0 0 0
EOF : 0 0 0
3) Out of bounds - jumps
JUMP : 0 127 255
EOF : 0 0 0
(a simple jump instruction with a maximum jump value)
4) Out of bounds - strings
STRING : 1 0 100 "foobar"
EOF : 0 0 0
Concerning going to the next instruction, I thought that one is
straightforward, but tinypy seems to stop at the end of the bytecode
even if there is no EOF instruction at the end. I'll have to see how
it detects it got to the end and then I'll write a test case. :)
--
Denis Kasak
Phil Hassey
| Denis, Can you get those worked up as test cases and popped into tests.py in your sandbox? They look good. Be sure to test both positive and negative jumps. -Phil |
--- On Fri, 8/1/08, Denis Kasak <denis...@gmail.com> wrote: |
From: Denis Kasak <denis...@gmail.com> |