> 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:
x86, x64 only. LTO only.
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.
If Intel considered x86 done, the WinTel world would have had no other alternative.
In Arm and x86 land you get CPUs that run even the old code 10% faster with every CPU generation. Meanwhile with say AMD NPUs XDNA1 land is not the same as XDNA2 land. You have to rewrite your algorithms if you want things to get faster. The promised VLIW benefits work as intended. You can run loads, stores and vector operations all in the same cycle without any issue.
Then there is the crazy world of TTAs (transport triggered architectures), which take the VLIW stuff and crank it up to extreme levels. Instead of having an ISA, you directly control the buses connecting the function units. If you have multiple buses, then you can perform multiple transfers in parallel. You can build a custom set of function units specifically for your application and the compiler will automatically turn your C code into transfer instructions for any design you can come up with.
Now the first idea you get is to obviously just crank up the number of buses from 1 to 2 to 4 to 8, but then you notice that the number of cycles to run your algorithm doesn't go down as quickly as you'd hoped. There are a number of reasons for this, but if I had to choose a reason that favors dynamic scheduling, it would be that most sequential programming languages, especially C, don't expose enough parallelism to the compiler to be able to take advantage of it at compile time. If you could prove to the compiler that two functions f and g do not mutate the same data (local mutable state is allowed), then the TTA compiler could produce a mixed instruction stream that blends both functions to be executed in parallel rather than sequentially. This is similar to SMT with the exception that the overhead is zero and that you are allowed to run nano threads that run for a few nano seconds.
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.
Valgrind is based on tagging whether a memory location is live or not. So, it would not just fail the intra-object OOB test, it would also fail the "out of bounds but in bounds" case: https://github.com/pizlonator/llvm-project-deluge/blob/delug...
unpaydijk•7mo ago
signa11•7mo ago
as @osivertsson has kindly pointed out, may you please access that, and share your insights here ? thanks !
ev234•7mo ago