Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.207,2.208
On Wed, Oct 11, 2000 at 12:04:52AM -0700, Tim Peters wrote:
default: fprintf(stderr, "Invalid argument to DUP_TOPX: %d!\n", oparg);
Hm, this fprintf is stray debugging code, added because I wasn't sure that a SystemError wouldn't crash the interpreter, given that the stack is utterly fu*d up at this point and we don't know what the compiler thinks is the stack size or block size here. (The snippet doesn't show it, but it also raises a SystemError.) Is it okay if I remove/comment this fprintf() before 2.0 final ? (At least it didn't say "awoogah, stray debugging code detected, this machine will self-destruct in 10 seconds" :-) Another-day-another-demerit<wink>-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
default: fprintf(stderr, "Invalid argument
to DUP_TOPX: %d!\n", oparg);
[Thomas Wouters]
Hm, this fprintf is stray debugging code, added because I wasn't sure that a SystemError wouldn't crash the interpreter, given that the stack is utterly fu*d up at this point and we don't know what the compiler thinks is the stack size or block size here. (The snippet doesn't show it, but it also raises a SystemError.) Is it okay if I remove/comment this fprintf() before 2.0 final ?
Suggest replacing it with: assert(!"Invalid argument to DUP_TOPX"); Then there's no cost in release mode, but we have a useful check in debug mode. ("assert(!string)" is a handy C debugging idiom more people should know about! It's semantically the same as assert(0) (i.e. will fail if ever reached), but unlike using a comment, using a string gets a useful msg displayed if it ever does fail).
(At least it didn't say "awoogah, stray debugging code detected, this machine will self-destruct in 10 seconds" :-)
Beats "Unto the root this day a brother is born" <wink -- a famous "can't happen" msg that, of course, got displayed, many years ago in a different project -- except the original was in Latin!>.
Another-day-another-demerit<wink>-ly y'rs,
That's a funny thing about working on Python: collect 5 demerits and you can exchange them for 1 brownie point! If you're not leaving crap behind, you're not eating enough Python code. continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs - tim
Suggest replacing it with:
assert(!"Invalid argument to DUP_TOPX");
Actually, I would recommend Py_FatalError("Invalid argument to DUP_TOPX") It's not quite the same since it also triggers in release mode. If, as Thomas says, this should never happen and can only be caused by garbled bytecode, a fatal error is proper rather than a SystemError. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 11 Oct 2000, Guido van Rossum wrote:
Py_FatalError("Invalid argument to DUP_TOPX")
It's not quite the same since it also triggers in release mode. If, as Thomas says, this should never happen and can only be caused by garbled bytecode, a fatal error is proper rather than a SystemError.
Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception. Unless I misunderstand the discussion completely. jumping-to-discussions-in-the-middle-ly y'rs, Z. -- Moshe Zadka <moshez@math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez
Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception.
Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 11 Oct 2000, Guido van Rossum wrote:
Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception.
Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing.
The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1... -- Moshe Zadka <moshez@math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez
Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception.
Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing.
The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1...
Huh? In restricted execution you shouldn't be allowed to mess with bytecode! --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Oct 11, 2000 at 10:03:00AM -0500, Guido van Rossum wrote:
Can't user Python code, fiddling around with bytecode, produce garbled bytecode? In that case, it seems even better to raise an exception.
Yes, they can produce garbled bytecode, and if that is detected, it's not safe to proceed. So a fatal error is the right thing.
The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1...
Huh? In restricted execution you shouldn't be allowed to mess with bytecode!
Well, I can see what Moshe means. You get a code object passed in, say, an untrusted pickle or some such. You want to execute it, but you don't want it to ruin your life. Causing the entire program to quit could be considered 'ruining'. On the other hand, if you can hand-tweak bytecode streams in that degree, you can f** up a lot more. On the one foot, though, most of the calls to Py_FatalError (as far as I can see) deal with initialization failures, or structures to which tweaked bytecode would not have access. On the other foot, it's probably possible to tweak bytecode to *get* access to those structures, or at least structures that don't like being dereferenced or DECREF'd. And there's probably more to consider, but I haven't got any public appendages left, and there might be children listening ;) All in all, Guido's probably right... If something like this happens, you don't want to continue. If the argument to DUP_TOPX is something other than what compile.c generates (between 1 and 5, inclusive, that is) something strange is going on internally. Better to quit now than delete c:\command.com by 'accident'. If people can do this to code being run in restricted environments, they can probably do worse things, too! Now I just need an OK from Jeremy, as the maitre d', and I'll check it in. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
[Moshe:]
The problem with letting Python code cause fatal errors is that it makes restricted execution much more difficult. Well, something to think about for 2.1...
[Guido:]
Huh? In restricted execution you shouldn't be allowed to mess with bytecode!
TW> Well, I can see what Moshe means. You get a code object passed TW> in, say, an untrusted pickle or some such. You want to execute TW> it, but you don't want it to ruin your life. Causing the entire TW> program to quit could be considered 'ruining'. On the other TW> hand, if you can hand-tweak bytecode streams in that degree, you TW> can f** up a lot more. Damn straight! If you're using restricted execution mode and accepting bytecode objects that weren't produced by a trusted Python compiler, you're nuts. I am not aware of any effort made to protect the Python VM from attack via malicious bytecode. TW> Now I just need an OK from Jeremy, as the maitre d', and I'll TW> check it in. Your table is ready. A checkin message will be accepted as gratuity. Jeremy
participants (5)
-
Guido van Rossum -
Jeremy Hylton -
Moshe Zadka -
Thomas Wouters -
Tim Peters