6 ms·

C and C++ are HARD to use correctly, but how many of those 60-70% vulnerabilities would have been resolved by just compiling with llvm address sanitizer? It wou

C and C++ are HARD to use correctly, but how many of those 60-70% vulnerabilities would have been resolved by just compiling with llvm address sanitizer? It would have stopped virtually all of them? https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/AddressSanitizer.html In many cases we already have the tools. The problem is that people are not using them. That said it is still in general a good thing to steer people away from C / C++ due to the languanges being very hard to use correctly.

techbrovanguard 3y ago
> It would have stopped virtually all of them? Do you have a source for that claim?
adgjlsfhk1 3y ago
asan only catches what your test suite covers. specifically, that doesn't include novel attacks.
- duped 3y ago
  That's kinda true, but if you use the compiler inserted address sanitizer code it will turn bugs from exploits into crashes. You can't exploit a OOB write if the write fails and the program crashes.
  - adgjlsfhk1 2y ago
    if you can afford the cost of that, just write your program in any other language c with asan is a lot slower than the safe alternatives
    - duped 2y ago
      I made another comment about exactly that, but was addressing the concern that asan doesn't make code safe.
duped 3y ago
> In many cases we already have the tools. The problem is that people are not using them. The problem with these tools are that the instrumentation code inserted by the compiler comes with a 50-100% program-wide performance loss (*) and that's not acceptable to C++ developers. So in practice, you don't just add -fsanitize=address to your builds, you add it to test builds and fuzz them. But now you're not just trusting your compiler, you're trusting your tests and coverage. The promise of Rust is that many of the memory safety bugs are forbidden at compile time in safe code, and the stuff that has to be checked at runtime (self referential data structures, out of bounds, etc) is able to be added more granularly with unsafe opt-outs where appropriate which means that you're not going to pay 50-100% in raw performance. * take this like all perf numbers with a heap of salt, do your own benchmarks and come to your own conclusions.
- pjmlp 3y ago
  To developers that cargo cult performance, that is. I have always enabled bounds checking, and never ever, did it matter for the kind of projects I was involved with. Not everyone is really writing a VR engine for a console rendering at 120 FPS, but just like everyone wants to be Google, so do much of those developers.
pjmlp 3y ago
The problem is that there are more compilers out there than clang, and clang isn't available everywhere.
GoblinSlayer 3y ago
They are hard to use when you absolutely want to use them the hard way, std::span can provide you lots of safety, but people don't use available tools.
- pjmlp 3y ago
  It provides none, unless you are using C++26 compiled with hardned standard library mode. If you care about safety use gsl::span instead.

techbrovanguard 3y ago

> It would have stopped virtually all of them? Do you have a source for that claim?

adgjlsfhk1 3y ago

asan only catches what your test suite covers. specifically, that doesn't include novel attacks.

duped 3y ago
That's kinda true, but if you use the compiler inserted address sanitizer code it will turn bugs from exploits into crashes. You can't exploit a OOB write if the write fails and the program crashes.
- adgjlsfhk1 2y ago
  if you can afford the cost of that, just write your program in any other language c with asan is a lot slower than the safe alternatives
  - duped 2y ago
    I made another comment about exactly that, but was addressing the concern that asan doesn't make code safe.

duped 3y ago

> In many cases we already have the tools. The problem is that people are not using them. The problem with these tools are that the instrumentation code inserted by the compiler comes with a 50-100% program-wide performance loss (*) and that's not acceptable to C++ developers. So in practice, you don't just add -fsanitize=address to your builds, you add it to test builds and fuzz them. But now you're not just trusting your compiler, you're trusting your tests and coverage. The promise of Rust is that many of the memory safety bugs are forbidden at compile time in safe code, and the stuff that has to be checked at runtime (self referential data structures, out of bounds, etc) is able to be added more granularly with unsafe opt-outs where appropriate which means that you're not going to pay 50-100% in raw performance. * take this like all perf numbers with a heap of salt, do your own benchmarks and come to your own conclusions.

pjmlp 3y ago
To developers that cargo cult performance, that is. I have always enabled bounds checking, and never ever, did it matter for the kind of projects I was involved with. Not everyone is really writing a VR engine for a console rendering at 120 FPS, but just like everyone wants to be Google, so do much of those developers.

pjmlp 3y ago

The problem is that there are more compilers out there than clang, and clang isn't available everywhere.

GoblinSlayer 3y ago

They are hard to use when you absolutely want to use them the hard way, std::span can provide you lots of safety, but people don't use available tools.

pjmlp 3y ago
It provides none, unless you are using C++26 compiled with hardned standard library mode. If you care about safety use gsl::span instead.