3 ms·

I mean, I feel a sane reading of the C Standard means reading "undefined" as "unspecified by the standard, but dependent on the trust and common sense of the co

by fao_ 3y ago

I mean, I feel a sane reading of the C Standard means reading "undefined" as "unspecified by the standard, but dependent on the trust and common sense of the compiler authors" -- which, you know, I don't know that that's any worse than "dependent on the trust and common sense of the npm package author" or "dependent on the trust and common sense of the rust cargo maintainer". Like, yes theoretically the compiler can do anything, but tangibly, coherently, most compilers deal with most UB in a sane way.

loup-vaillant 3y ago
> but tangibly, coherently, most compilers deal with most UB in a sane way. It depends. In some cases, really, no they do not. Compilers have been caught deleting security checks when they noticed that the only way to reach the error case was to trigger UB… and since "UB doesn't exist", the error case is considered dead, and the whole test is deleted. Sometimes this leads to remote code execution vulnerabilities, that if exploited could actually result in your hard drive being encrypted, or a keylogger being installed. UB is really, really scary.
- bippihippi1 3y ago
  cite source?
  - dzaima 3y ago
    Here's one case: https://godbolt.org/z/aM89Eqs3v https://godbolt.org/z/aM89Eqs3v - the 'p == NULL' check is gone. Not directly harmful if the null page is inaccessible (which it's gonna be for most user-space stuff), but if it's accessible, it's quite bad. (and, fwiw, there's -fno-delete-null-pointer-checks to stop the compilers from doing this) And another commonly mentioned one: https://godbolt.org/z/6bf17W1Ee https://godbolt.org/z/6bf17W1Ee
- maccard 3y ago
  > Sometimes this leads to remote code execution vulnerabilities, that if exploited could actually result in your hard drive being encrypted, or a keylogger being installed. Have you got a link to a CVE of an RCE that was caused by UB being exploited by an optimizer? Im with you that UB is dangerous, but let's be honest in 98% of situations it's correct to assume that integer overflow can't happen, and that if you pass a pointer into a function and don't check it that the call site has checked it.
  - loup-vaillant 3y ago
    No link, but I do recall a CVE talking about a buffer overflow vulnerability that could be traced back to a bounds check being removed by the compiler because the only way to go out of bounds was to overflow a signed integer. (Signed integer overflow is UB, and "UB does not exist", so the check was "dead".)
  - tedunangst 3y ago
    The Linux kernel used to have lots of deref then null check bugs, but you could map memory at address zero, controlling what should have been kernel memory.
- fao_ 3y ago
  Right, and that's a breach of the social contract vis a vis compiler authors and the language users, which is a social problem. The lack of safety here is because the GNU programmers detect the UB and decide to cowboy it. If you take the time to actually read Annex J of the C language you'll see that most of what is intended by "UB" is just "The language or platform could be buggy or the spec could be weird".
fanf2 3y ago
This is not true in fact or in practice. For example, a compiler can assume that a variable sized shift is in range, then use value range propagation to eliminate tests, which can be very confusing if you expect the shift to be implicitly & 63.
kibwen 3y ago
> I don't know that that's any worse than "dependent on the trust and common sense of the npm package author" or "dependent on the trust and common sense of the rust cargo maintainer" You don't need to rely on the trust and common sense of anyone in those cases, because oversized shifts aren't undefined behavior in Javascript or Rust. If C (or C++, or any other language) wants the same benefit, they can just say that it's not undefined behavior, and thereby require implementations to define the behavior somehow. And "backwards compatibility" isn't an excuse here: UB means that, currently, anything can happen, so having the standard specify that one particular thing happens is an entirely backwards-compatible change.
userbinator 3y ago
but tangibly, coherently, most compilers deal with most UB in a sane way. They used to, but unfortunately increasingly not so much now. (Since the most popular ones are open-source, we should theoretically have the power to change that.)
taway1237 3y ago
>Like, yes theoretically the compiler can do anything, but tangibly, coherently, most compilers deal with most UB in a sane way. I have to disagree - I do a lot of hacky low-level stuff, and C/C++ compilers love to "break" my code. I mean they have a right to, because I know it's technically UB, but I end up playing a game with the compiler where I "trick" it so it doesn't notice the UB and delete my whole function silently.

by fao_ 3y ago

loup-vaillant 3y ago

> but tangibly, coherently, most compilers deal with most UB in a sane way. It depends. In some cases, really, no they do not. Compilers have been caught deleting security checks when they noticed that the only way to reach the error case was to trigger UB… and since "UB doesn't exist", the error case is considered dead, and the whole test is deleted. Sometimes this leads to remote code execution vulnerabilities, that if exploited could actually result in your hard drive being encrypted, or a keylogger being installed. UB is really, really scary.

bippihippi1 3y ago
cite source?
- dzaima 3y ago
  Here's one case: https://godbolt.org/z/aM89Eqs3v https://godbolt.org/z/aM89Eqs3v - the 'p == NULL' check is gone. Not directly harmful if the null page is inaccessible (which it's gonna be for most user-space stuff), but if it's accessible, it's quite bad. (and, fwiw, there's -fno-delete-null-pointer-checks to stop the compilers from doing this) And another commonly mentioned one: https://godbolt.org/z/6bf17W1Ee https://godbolt.org/z/6bf17W1Ee
maccard 3y ago
> Sometimes this leads to remote code execution vulnerabilities, that if exploited could actually result in your hard drive being encrypted, or a keylogger being installed. Have you got a link to a CVE of an RCE that was caused by UB being exploited by an optimizer? Im with you that UB is dangerous, but let's be honest in 98% of situations it's correct to assume that integer overflow can't happen, and that if you pass a pointer into a function and don't check it that the call site has checked it.
- loup-vaillant 3y ago
  No link, but I do recall a CVE talking about a buffer overflow vulnerability that could be traced back to a bounds check being removed by the compiler because the only way to go out of bounds was to overflow a signed integer. (Signed integer overflow is UB, and "UB does not exist", so the check was "dead".)
- tedunangst 3y ago
  The Linux kernel used to have lots of deref then null check bugs, but you could map memory at address zero, controlling what should have been kernel memory.
fao_ 3y ago
Right, and that's a breach of the social contract vis a vis compiler authors and the language users, which is a social problem. The lack of safety here is because the GNU programmers detect the UB and decide to cowboy it. If you take the time to actually read Annex J of the C language you'll see that most of what is intended by "UB" is just "The language or platform could be buggy or the spec could be weird".

fanf2 3y ago

This is not true in fact or in practice. For example, a compiler can assume that a variable sized shift is in range, then use value range propagation to eliminate tests, which can be very confusing if you expect the shift to be implicitly & 63.

kibwen 3y ago

> I don't know that that's any worse than "dependent on the trust and common sense of the npm package author" or "dependent on the trust and common sense of the rust cargo maintainer" You don't need to rely on the trust and common sense of anyone in those cases, because oversized shifts aren't undefined behavior in Javascript or Rust. If C (or C++, or any other language) wants the same benefit, they can just say that it's not undefined behavior, and thereby require implementations to define the behavior somehow. And "backwards compatibility" isn't an excuse here: UB means that, currently, anything can happen, so having the standard specify that one particular thing happens is an entirely backwards-compatible change.

userbinator 3y ago

but tangibly, coherently, most compilers deal with most UB in a sane way. They used to, but unfortunately increasingly not so much now. (Since the most popular ones are open-source, we should theoretically have the power to change that.)

taway1237 3y ago

>Like, yes theoretically the compiler can do anything, but tangibly, coherently, most compilers deal with most UB in a sane way. I have to disagree - I do a lot of hacky low-level stuff, and C/C++ compilers love to "break" my code. I mean they have a right to, because I know it's technically UB, but I end up playing a game with the compiler where I "trick" it so it doesn't notice the UB and delete my whole function silently.