4 ms·

Sulong: Finding Errors in C Programs [pdf]

72 points by matt_d 9y ago

mcguire 9y ago
"Unlike higher-level languages, the C standard does not define any checks that could detect such erroneous accesses ["buffer overflows, NULL pointer dereferences, and use-after-free errors"] and then abort the program." Stephen Kell, in "Some Were Meant for C: The Endurance of an Unmanageable Language", writes a simple and fairly strong argument that, for C, that's not a valid complaint. Since C is a systems language, the proper place to look for those (particularly runtime) checks is in the combination of the C standard and the system it's running on, particularly the hardware. Edit: "Compiler optimizations can lead to false positives . For example, a false positive that was found in an ASan-instrumented Firefox build was caused by load-widening [55] where a series of loads is transformed into a single load of several memory values at once while potentially exceeding the bounds of an object. Due to platform-specific alignment requirements, such an optimization can be correct at the system level; however, ASan classified it as a bug because the access would be out of bounds in C." Yep, there we go.
- pjmlp 9y ago
  Systems languages looked quite different in what it meant to be unsafe before C took the keys of the kingdom.
  - girvo 9y ago
    Right. I think a lot of people forget that C wasn’t (and isn’t!) the only systems language that was in heavy usage, and indeed a lot of its predecessors and contemporaries were much safer. But hey, worse is better, and C won, so I’m fighting a losing battle here I think.
- rurban 9y ago
  > "Unlike higher-level languages, the C standard does not define any checks that could detect such erroneous accesses ["buffer overflows, NULL pointer dereferences, and use-after-free errors"] and then abort the program." Actually C11 Annex K does. It's just that it is ignored because it came from Microsoft.
mcguire 9y ago
Tl;dr: They created a run-time bug finder similar to valgrind by creating a LLVM IR interpreter in Java. It finds bugs and is much faster than valgrind (which is a win). They go on with: "In this paper, we have presented a novel bug-finding tool for C programs that is based on abstraction of the underlying machine. We implemented our approach in a tool called Safe Sulong, which discovered several errors in open-source projects that current bug-finding tools could not find. By using dynamic compilation, Safe Sulong reaches a peak performance that is comparable to that of Clang -O0 , and even that of Clang -O3 in some cases."
egnehots 9y ago
Whoa, dolphins are so smart.
dhekir 9y ago
"we implemented a libc that is written in standard C and does not rely on any GNU extensions." Does anyone know if such library is available somewhere?
- digikata 9y ago
  http://www.musl-libc.org http://www.musl-libc.org although it may not be absolutely 100% that way. From the FAQ: > When building musl, you will also need a C99 compiler with support for gcc-style __asm__ statements and assembly source files, and weak symbol support in the linker. gcc 3.3 or later (with the GNU assembler and linker) and clang 3.2 or later are known to work.
  - dhekir 9y ago
    Sorry, I meant their libc. That would be very useful if open-sourced. They state that "we provide our own libc that is written in standard C and is optimized for safety instead of performance", but I don't see where to find it.
- rurban 9y ago
  The bounds checks, null and zero checks are also in safeclib, which is written in pure C99 without asm, getting the same speed as glibc on clang-7. https://github.com/rurban/safeclib https://github.com/rurban/safeclib on top of an existing unsafe libc, if glibc, bsd, musl or windows msvcrt/ulibc.
sanxiyn 9y ago
The idea is reminiscent of Miri for Rust: https://github.com/solson/miri https://github.com/solson/miri
caf 9y ago
Sounds like it may have similar coverage to tis-interpreter ( https://trust-in-soft.com/tis-interpreter/ https://trust-in-soft.com/tis-interpreter/ ), but significantly faster.

72 points by matt_d 9y ago

"Unlike higher-level languages, the C standard does not define any checks that could detect such erroneous accesses ["buffer overflows, NULL pointer dereferences, and use-after-free errors"] and then abort the program." Stephen Kell, in "Some Were Meant for C: The Endurance of an Unmanageable Language", writes a simple and fairly strong argument that, for C, that's not a valid complaint. Since C is a systems language, the proper place to look for those (particularly runtime) checks is in the combination of the C standard and the system it's running on, particularly the hardware. Edit: "Compiler optimizations can lead to false positives . For example, a false positive that was found in an ASan-instrumented Firefox build was caused by load-widening [55] where a series of loads is transformed into a single load of several memory values at once while potentially exceeding the bounds of an object. Due to platform-specific alignment requirements, such an optimization can be correct at the system level; however, ASan classified it as a bug because the access would be out of bounds in C." Yep, there we go.

pjmlp 9y ago
Systems languages looked quite different in what it meant to be unsafe before C took the keys of the kingdom.
- girvo 9y ago
  Right. I think a lot of people forget that C wasn’t (and isn’t!) the only systems language that was in heavy usage, and indeed a lot of its predecessors and contemporaries were much safer. But hey, worse is better, and C won, so I’m fighting a losing battle here I think.
rurban 9y ago
> "Unlike higher-level languages, the C standard does not define any checks that could detect such erroneous accesses ["buffer overflows, NULL pointer dereferences, and use-after-free errors"] and then abort the program." Actually C11 Annex K does. It's just that it is ignored because it came from Microsoft.

mcguire 9y ago

Tl;dr: They created a run-time bug finder similar to valgrind by creating a LLVM IR interpreter in Java. It finds bugs and is much faster than valgrind (which is a win). They go on with: "In this paper, we have presented a novel bug-finding tool for C programs that is based on abstraction of the underlying machine. We implemented our approach in a tool called Safe Sulong, which discovered several errors in open-source projects that current bug-finding tools could not find. By using dynamic compilation, Safe Sulong reaches a peak performance that is comparable to that of Clang -O0 , and even that of Clang -O3 in some cases."

egnehots 9y ago

Whoa, dolphins are so smart.

dhekir 9y ago

"we implemented a libc that is written in standard C and does not rely on any GNU extensions." Does anyone know if such library is available somewhere?

digikata 9y ago
http://www.musl-libc.org http://www.musl-libc.org although it may not be absolutely 100% that way. From the FAQ: > When building musl, you will also need a C99 compiler with support for gcc-style __asm__ statements and assembly source files, and weak symbol support in the linker. gcc 3.3 or later (with the GNU assembler and linker) and clang 3.2 or later are known to work.
- dhekir 9y ago
  Sorry, I meant their libc. That would be very useful if open-sourced. They state that "we provide our own libc that is written in standard C and is optimized for safety instead of performance", but I don't see where to find it.
rurban 9y ago
The bounds checks, null and zero checks are also in safeclib, which is written in pure C99 without asm, getting the same speed as glibc on clang-7. https://github.com/rurban/safeclib https://github.com/rurban/safeclib on top of an existing unsafe libc, if glibc, bsd, musl or windows msvcrt/ulibc.

sanxiyn 9y ago

The idea is reminiscent of Miri for Rust: https://github.com/solson/miri https://github.com/solson/miri

caf 9y ago

Sounds like it may have similar coverage to tis-interpreter ( https://trust-in-soft.com/tis-interpreter/ https://trust-in-soft.com/tis-interpreter/ ), but significantly faster.