1 The numbers on memory safety should nowadays separate between spatial ones (bounds-checked in most languages with sane flags) and temporal ones. Temporal ones will be lower than 70%.
2 The article does not mention (compilation) time costs of static checks and its influence on growing code bases, which is a more fundamental system trade-off on scalability and development velocity/efficiency.
> Wrap unsafe code with safe interfaces
3 That sounds like an equivalent of using permission-based separation logic hopefully soon available for LLVM.
> "Get good" is not a strategy
4 Being good is all about knowing exactly techniques, processes, and tools with exact trade-offs and applying them; so I would expect here teaching process knowledge about static and dynamic analysis strategies, tooling and tactics to eliminate bug classes.
However, neither have we sane bug classes overviews nor can we generate sane probabilities/statistics of occurrence based on source code and available static and dynamic analysis even when ignoring functionality requirements.
This reads somewhat like developers should "stay mediocre" and "trust the tools", even though "Get good and improve processes for groups" is probably the here intended strategy.
What do you mean by "temporal ones will be lower than 70%"? Are you suggesting --- referring to the article's cite --- that subcomponent ports to Rust reduce spatial vulnerabilities more than temporal ones? If so, why do you believe that?
I would expect more of the opposite for languages offering easy to enable bound checks. Only observing the general trend for when bound checks are available (and used) would be helpful information.
Temporal ones will remain tricky to debug until at least static + dynamic analysis via scheduling in kernel, hypervisor/simulation and/or run-time will become common-place. Probably even longer, because analysis is cumbersome for bigger programs without Seperation Logic (like Rust has).
If you're talking about the impact of replacing a subcomponent in a larger C/C++ codebase with a memory safe language and saying you'd expect that to make less of an impact on the temporal memory safety issues latent in the remaining C/C++ code, I guess I get that.
If you're saying that you think memory safe languages are less successful at dealing with their own temporal memory safety concerns than spatial memory safety concerns, that doesn't make sense to me and I would push back on it.
I do agree with point 1 and with most of point 2 besides some more arcane things like intentionally racy memory access and some write-cache eviction instruction not being properly modeled (in for example Rust).
2 The article does not mention (compilation) time costs of static checks and its influence on growing code bases, which is a more fundamental system trade-off on scalability and development velocity/efficiency.
> Wrap unsafe code with safe interfaces
3 That sounds like an equivalent of using permission-based separation logic hopefully soon available for LLVM.
> "Get good" is not a strategy
4 Being good is all about knowing exactly techniques, processes, and tools with exact trade-offs and applying them; so I would expect here teaching process knowledge about static and dynamic analysis strategies, tooling and tactics to eliminate bug classes. However, neither have we sane bug classes overviews nor can we generate sane probabilities/statistics of occurrence based on source code and available static and dynamic analysis even when ignoring functionality requirements. This reads somewhat like developers should "stay mediocre" and "trust the tools", even though "Get good and improve processes for groups" is probably the here intended strategy.