| |||||||||||||
Cryptographic weakness on Debian systemsCryptographic weakness on Debian systemsPosted May 14, 2008 10:46 UTC (Wed) by nix (subscriber, #2304)In reply to: Cryptographic weakness on Debian systems by Ross Parent article: Cryptographic weakness on Debian systems
It's even worse than that. Because the Standard does not define the behaviour of a translator running over code that invokes undefined behaviour, the program could legally remove all your files *as soon as it started up*. The compiler itself could do it when compiling said code. In practice, a compiler that did that, or that responded to code invoking undefined behaviour by buffer-overrunning or imploding in flames, would be considered to have rather big QoI problems: but it's not unheard of by any means. Remember the GCC `bailing out' message from days of yore? That was emitted when the compiler *segfaulted*, but was prettied up somewhat in the vague hope that people wouldn't complain about it. (These days the same problems yield an 'internal compiler error', which *is* considered a bug: but if it happens on invalid code, not a very important bug.)
(Log in to post comments)
Cryptographic weakness on Debian systems Posted May 14, 2008 14:28 UTC (Wed) by welinder (guest, #4699) [Link] > It's even worse than that. Because the Standard does not > define the behaviour of a translator running over code that > invokes undefined behaviour, the program could legally remove > all your files *as soon as it started up*. The compiler itself > could do it when compiling said code. In this case, no. That would require that the translator could determine that undefined behaviour would happen. That is not possible in any, but the most trivial, of programs. For example, link with a malloc that always returns NULL -- boring, but ok for the C standard -- and the problematic code will not be reached.
Cryptographic weakness on Debian systems Posted May 14, 2008 19:38 UTC (Wed) by nix (subscriber, #2304) [Link] There's no requirement for the code incurring undefined behaviour to be executed. The Standard imposes requirements on *translators*, and the translator sees that code. However, compilation must succeed `unless [the translator] can determine that every possible execution of that program would result in undefined behavior' (or there's a syntax error or constraint violation, neither of which is true here), which could be read to imply that if the translator can determine that there are several possible ways to interpret some part of a program, some undefined and some not, the translator must assume that the not-undefined interpretation holds. This sometimes has incredibly counterintuitive consequences, so as a QoI issue it is not always followed. (e.g. in this case I suspect it would be permitted for a compiler to spot that the problematic code is not executed if malloc() always returns NULL, and expand the appropriate malloc() calls inline to a constant NULL on the basis that returning anything else would incur undefined behaviour! In practice, this wouldn't get done.)
|
|||||||||||||