microsoft
use-after-free, complementary library
I just came across this project and though I'd let you guys know about the complementary "language extension" library (note, shameless plug) for higher level C/C++ application code (as opposed to low-level system code).
I haven't read your whole spec document yet, but it seems to me like you are addressing the bounds-checking issue but not the "use-after-free" or "use-of-uninitialized-value" issues? While the bounds-checking is great, "use-after-free" seems to be responsible for more critical vulnerabilities these days. At least if you go by Pwn2Own or Chromium's critical security bug tracker. Have you guys considered addressing the use-after-free issue? If so, you might consider introducing a low-level pointer type analogous to mse::TRegisteredPointer<> that is automatically set to null when the target object is deallocated.
Thanks for the pointer to your library! I agree that the two efforts are complementary. We are interested in use-after-free and use-of-initialized value problems as well. In terms of the order that we're pursuing problems, we'll be looking at initialization, null-terminated arrays, type casts first, and then looking at use-after-free.
I like the approach in your library of capturing existing patterns that are safe and prevent misuse (such as stack allocation of objects, reference-counting, or using a proxy with the underlying pointer being nulled out after the object is freed). I think the approach is a sensible way to go.
I found your analysis of the C++ standard library interesting. I agree that there are patterns in the library that are problematic for checked code. It is tough to reason about pointers into the middle of objects (such as what can happen with std::vector). That leads to needing to reason about object invariants and how method calls affect those object invariants.
Thanks for the feedback.
One of the advantages of our "language extension" approach is that it empowers the programmer to judiciously use "unsafe" code in areas where performance is critical. So I just ran across this project and found it interesting: http://dslab.epfl.ch/proj/asap/ If I understand correctly, they seem to be using run-time profiling info to automatically disable AddressSantizer and Softbound safety checks in just the most performance critical parts of the code. That sounds like a solution that might be tougher to compete against, no? I wonder how well it works in practice.
Also, in chapter 11.3.1 of your spec pdf, you explain the decision not to change the "address-of" operator by pointing out that leaving it as is doesn't result in the introduction of any new unsafe pointers that weren't already explicitly declared. In my case, I decided to override the native address-of operator because the extensive use of "auto" in modern C++ would result in lots of unsafe pointers where they weren't explicitly intended. In part to address the compatibility with legacy code issue, I provide two "registered pointer" types - one that implicitly converts to a native pointer, and one that requires explicit conversion. Implicit conversion being not ideal for the reasons pointed out in your spec. So just out of curiosity, as someone who doesn't deal with a lot of "system" code, is system code generally strictly C code? I mean would "auto" be frowned upon in system code these days?
I guess I'm contemplating about where "safety enhanced" C/C++ is needed the most, and it seems to me that one case might be something like the (eternally vulnerable) Firefox browser. (I guess that would apply to the Edge browser too, though I assume it's not as buggy.) Now, does browser code count as "system" code? I mean, isn't the browser the new OS? Presumably browsers would employ both low-level C code and higher-level C++ code. My understanding is that their ultimate solution is to rewrite the whole browser in Rust. I would think that a solution of converting their code to "safe C/C++" would be a competitive in both effort required and resulting security. Don't you think? Btw, I notice the Tor project seems pretty desperate for a solution to Firefox's security issues: https://blog.torproject.org/blog/tor-browser-55a4-hardened-released
Or is Checked C primarily directed at embedded systems that don't use the heap?