4 ms·

Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C s

Why aren't people using safe C compilers or libraries and stuff like that? Do they affect performance that much? If yes then what about libraries written in C so that they can be used in other languages (meaning performance is not the number one concern)?

LoganDark 3y ago
...What is a "safe C compiler"?
- deusum 3y ago
  ...a textbook oxymoron?
- ReptileMan 3y ago
  Check on the fiction section sir. Here is the CS one. Although I think all the C compilers are safe ish lately. I haven't seen exploits that target defects in output. Usually the error is ID10T located in the prekeyboard device.
- littlestymaar 3y ago
  rustc /s
- adrian_b 3y ago
  All decent C compilers have compilation options so that at run-time any undefined actions, including integer overflow and out-of-bounds accesses, will be trapped. The only problem is that these options are not the default and most C developers do not use them, especially for release versions. I always use them, including for releases. In the relatively rare cases when this has a performance impact, I disable the sanitize options only for the functions where this matters and only after an analysis that guarantees that events like overflows or out-of-bounds accesses cannot happen. Despite the hype, by default Rust is not safer than C compiled with the right options, because the default for Rust releases is also to omit many run-time checks. Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. For now, when safety is desired, both C and Rust must be compiled with non-default options.
  - planede 3y ago
    Do you release with `-fsanitize=address` or what?
  - hannob 3y ago
    FWIW it is not recommended to use asan+co for release builds. These are designed as debugging tools, if you use them in production builds they may actually open up new bugs. See also: https://www.openwall.com/lists/oss-security/2016/02/17/9 https://www.openwall.com/lists/oss-security/2016/02/17/9 I don't think anyone has built anything practically usable that is meant for production, though it wouldn't be impossible to do so.
    - astrange 3y ago
      It's more or less okay to use UBSan in production though, and that can be good. But sometimes DoS is considered an exploit, and in that case you don't want to make things easier to crash.
  - steveklabnik 3y ago
    > Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. Which checks are you thinking of? The only thing that comes to mind is that integer overflow wraps instead of panics, but given that bounds are checked, it is still going to be a panic or logic bug rather than a buffer overflow.
  - insanitybit 3y ago
    It sounds like you're referring to sanitizers. 1. Notably, some sanitizers are not intended for production use. I think this has changed a bit for asan but at one point it made vulns easier to exploit. These aren't mitigations. 2. They're extremely expensive. You need tons of bookkeeping for pointers for them to work. If you're willing to take that hit I don't really understand why you're using C, just use a GC'd language, which is probably going to be faster at that point. > Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. The only thing Rust turns off at release is that unsigned integer overflows panic in debug but wrap on release. That wrap can not lead to memory unsafety.
- blackpill0w 3y ago
  Not necessarily a "safe compiler" but maybe safe library for containers and things like that. It seems to me that most if not all major C projects just run sanitizers and static analysers.
vesinisa 3y ago
This is a great question. The answer is that it's literally impossible to write a "safe C compiler" since the language is inherently memory unsafe. There are various static analysis tools that can try to simulate C programs and try to automatically discover memory management bugs, but due to fundamental limitations of computation they can never catch all possible faults.
- blackpill0w 3y ago
  How difficult is it to make a compiler extension that remembers buffers' size and checks if we're overflowing at each access? It could be used at least just in debug versions of critical software. It doesn't sound impossible to me but I know nothing about compiler development :)
  - refulgentis 3y ago
    It's trivial but Big Tech is in bed with Big Hacker Or it's hard like everyone keeps saying. I'm going with the second option
  - pjc50 3y ago
    > remembers buffers' size Where? Once you have a bare pointer, you've lost track of what the original definition might have been, so you (the compiler / runtime / programmer) have no way of knowing that you've exceeded the size.
    - astrange 3y ago
      That's not true, it is merely true on most ABIs. The only case where C really erases this information is casting to uintptr_t and back.
      - Gibbon1 3y ago
        gcc also has some builtins to check pointer sizes when the compiler is able to figure it out. https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Object-Size-Checking.html https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Object-Size-Che... Which is why I harp on the idea that the real problem is the gold bricks on WG14 who are intentionally blocking improvements to make C safer. Also point out that if you can implement C on 16bit 0x86's segmented architecture you can certainly implement C with phat pointers too.
pjc50 3y ago
You can't really retrofit safety to C. The best that can be achieved is sel4, which while it is written in C has a separate proof of its correctness: https://github.com/seL4/l4v https://github.com/seL4/l4v The proof is much, much more work than the microkernel itself. A proof for something as large as webP might take decades.
- LoganDark 3y ago
  > A proof for something as large as webP might take decades. Assuming that it is even provable in the first place.

LoganDark 3y ago

...What is a "safe C compiler"?

deusum 3y ago
...a textbook oxymoron?
ReptileMan 3y ago
Check on the fiction section sir. Here is the CS one. Although I think all the C compilers are safe ish lately. I haven't seen exploits that target defects in output. Usually the error is ID10T located in the prekeyboard device.
littlestymaar 3y ago
rustc /s
adrian_b 3y ago
All decent C compilers have compilation options so that at run-time any undefined actions, including integer overflow and out-of-bounds accesses, will be trapped. The only problem is that these options are not the default and most C developers do not use them, especially for release versions. I always use them, including for releases. In the relatively rare cases when this has a performance impact, I disable the sanitize options only for the functions where this matters and only after an analysis that guarantees that events like overflows or out-of-bounds accesses cannot happen. Despite the hype, by default Rust is not safer than C compiled with the right options, because the default for Rust releases is also to omit many run-time checks. Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. For now, when safety is desired, both C and Rust must be compiled with non-default options.
- planede 3y ago
  Do you release with `-fsanitize=address` or what?
- hannob 3y ago
  FWIW it is not recommended to use asan+co for release builds. These are designed as debugging tools, if you use them in production builds they may actually open up new bugs. See also: https://www.openwall.com/lists/oss-security/2016/02/17/9 https://www.openwall.com/lists/oss-security/2016/02/17/9 I don't think anyone has built anything practically usable that is meant for production, though it wouldn't be impossible to do so.
  - astrange 3y ago
    It's more or less okay to use UBSan in production though, and that can be good. But sometimes DoS is considered an exploit, and in that case you don't want to make things easier to crash.
- steveklabnik 3y ago
  > Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. Which checks are you thinking of? The only thing that comes to mind is that integer overflow wraps instead of panics, but given that bounds are checked, it is still going to be a panic or logic bug rather than a buffer overflow.
- insanitybit 3y ago
  It sounds like you're referring to sanitizers. 1. Notably, some sanitizers are not intended for production use. I think this has changed a bit for asan but at one point it made vulns easier to exploit. These aren't mitigations. 2. They're extremely expensive. You need tons of bookkeeping for pointers for them to work. If you're willing to take that hit I don't really understand why you're using C, just use a GC'd language, which is probably going to be faster at that point. > Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C. The only thing Rust turns off at release is that unsigned integer overflows panic in debug but wrap on release. That wrap can not lead to memory unsafety.
blackpill0w 3y ago
Not necessarily a "safe compiler" but maybe safe library for containers and things like that. It seems to me that most if not all major C projects just run sanitizers and static analysers.

vesinisa 3y ago

This is a great question. The answer is that it's literally impossible to write a "safe C compiler" since the language is inherently memory unsafe. There are various static analysis tools that can try to simulate C programs and try to automatically discover memory management bugs, but due to fundamental limitations of computation they can never catch all possible faults.

blackpill0w 3y ago
How difficult is it to make a compiler extension that remembers buffers' size and checks if we're overflowing at each access? It could be used at least just in debug versions of critical software. It doesn't sound impossible to me but I know nothing about compiler development :)
- refulgentis 3y ago
  It's trivial but Big Tech is in bed with Big Hacker Or it's hard like everyone keeps saying. I'm going with the second option
- pjc50 3y ago
  > remembers buffers' size Where? Once you have a bare pointer, you've lost track of what the original definition might have been, so you (the compiler / runtime / programmer) have no way of knowing that you've exceeded the size.
  - astrange 3y ago
    That's not true, it is merely true on most ABIs. The only case where C really erases this information is casting to uintptr_t and back.
    - Gibbon1 3y ago
      gcc also has some builtins to check pointer sizes when the compiler is able to figure it out. https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Object-Size-Checking.html https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Object-Size-Che... Which is why I harp on the idea that the real problem is the gold bricks on WG14 who are intentionally blocking improvements to make C safer. Also point out that if you can implement C on 16bit 0x86's segmented architecture you can certainly implement C with phat pointers too.

pjc50 3y ago

You can't really retrofit safety to C. The best that can be achieved is sel4, which while it is written in C has a separate proof of its correctness: https://github.com/seL4/l4v https://github.com/seL4/l4v The proof is much, much more work than the microkernel itself. A proof for something as large as webP might take decades.

LoganDark 3y ago
> A proof for something as large as webP might take decades. Assuming that it is even provable in the first place.