> The findings highlight significant variations
in the theoretical detection capabilities of these techniques
and reveal that, in practice, the implementations of most
available sanitizers fall short of their conceptual potential.
Furthermore, the evaluation demonstrates the complexities
and diversity of memory bugs in C/C++, as well as the
challenges associated with detecting them. For instance, our
results show that SoftBound+CETS, a conceptually complete sanitizer, misses nearly a quarter of spatial memory
bugs in its original implementation, while ASan, likely the
most widely used memory sanitizer, cannot detect 50% of
use-after-* bugs and any non-linear overflows and under-
flows. Ultimately, our evaluation concludes that no sanitizer
currently provides complete temporal or spatial memory
safety
Weird that Infer [1] was not included in the evaluation. It supports C/C++ and its underlying reasoning framework (Separation Logic [2]) is exactly geared towards checking memory safety.
Sanitizers are runtime tools, not static analysis tools.
Static analyzers are also virtually never sound as sound tools produce an outrageous number of false positives, especially when languages that so easily permit nonlocal mutation.
I wonder how true the assertion "This performance is partly achieved by sacrificing memory safety" is today. I suspect a sufficiently advanced compiler can remove bounds checks where they are provably unnecessary, and a sufficiently advanced CPU can run the remaining checks in parallel with the array accesses. But it'd be interesting if there's been any research on that.
(A sufficiently advanced programming language can avoid the entire issue by writing loops as map, fold, etc. but we're talking about C here.)
> I suspect a sufficiently advanced compiler can remove bounds checks where they are provably unnecessary,
That’s true by definition, isn’t it?
> and a sufficiently advanced CPU can run the remaining checks in parallel with the array accesses.
But it still would slow down the program, as the CPU would have to commit resources to that bound checking that it then cannot use for doing other things.
Much like how Intel Itanium would've taken over the world with the VLIW revolution if only we had one of these 'sufficiently advanced compilers'. It's a very vague statement that doesn't really mesh with reality. Decades of research in compilers have yet to yield one.
I think you're right, and it's up to the programming language to provide optimization friendly primitives that fit into the mold of what we can prove as in-bounds.
Speculative execution will never be free because those bounds checks will take up space in the execution pipeline that could've been used for other instructions.
16 comments
[ 6.5 ms ] story [ 48.7 ms ] thread> The findings highlight significant variations in the theoretical detection capabilities of these techniques and reveal that, in practice, the implementations of most available sanitizers fall short of their conceptual potential. Furthermore, the evaluation demonstrates the complexities and diversity of memory bugs in C/C++, as well as the challenges associated with detecting them. For instance, our results show that SoftBound+CETS, a conceptually complete sanitizer, misses nearly a quarter of spatial memory bugs in its original implementation, while ASan, likely the most widely used memory sanitizer, cannot detect 50% of use-after-* bugs and any non-linear overflows and under- flows. Ultimately, our evaluation concludes that no sanitizer currently provides complete temporal or spatial memory safety
It is unmaintained:
https://github.com/Fraunhofer-AISEC/softboundcets
x86, x64 only. LTO only.
[1] https://fbinfer.com/
[2] https://en.wikipedia.org/wiki/Separation_logic
Static analyzers are also virtually never sound as sound tools produce an outrageous number of false positives, especially when languages that so easily permit nonlocal mutation.
(A sufficiently advanced programming language can avoid the entire issue by writing loops as map, fold, etc. but we're talking about C here.)
That’s true by definition, isn’t it?
> and a sufficiently advanced CPU can run the remaining checks in parallel with the array accesses.
But it still would slow down the program, as the CPU would have to commit resources to that bound checking that it then cannot use for doing other things.
Much like how Intel Itanium would've taken over the world with the VLIW revolution if only we had one of these 'sufficiently advanced compilers'. It's a very vague statement that doesn't really mesh with reality. Decades of research in compilers have yet to yield one.
I think you're right, and it's up to the programming language to provide optimization friendly primitives that fit into the mold of what we can prove as in-bounds.
Speculative execution will never be free because those bounds checks will take up space in the execution pipeline that could've been used for other instructions.
Fil-C is specifically engineered to catch everything so it would be interesting to check it against their tests
So why isn't MESH part of the evaluation? And why isn't it mentioned even once in the paper?
But I also miss valgrind, which is precise, just very slow. I wonder if valgrind detects intra-object OOBAs.