[nickpsecurity]

"Like several times slower that executables compiled normally. "

That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Remember that these also knock out almost every root cause of code injections in C apps with SVA-OS covering whole Linux kernel. Might be worth buying a second CPU to cover the overheads. ;)

"The TOR project tried to build firefox using them, but they couldn't successfully build it"

I wasn't aware of that. Thanks for telling me. Shows some work needs to be done. Would've been nice if they were more specific than "they didn't work." I was holding off on applying them to Tor anyway since such services must do covert-channel analyses. I'm not sure what effect these techs have on that. I recommended redoing it in SPARK Ada with Kemmerer's method for covert channel analysis.

"And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives."

I disagree. The reason is that there's way more tooling for statically analyzing, verifying, certifying object code of, and so on for C programs. Very little for C++ in comparison. So, taking up C++ gives you the few measures of safety it provides while forgoing tech you can get in C such as Astree Analyzer or CompCert. Too much a sacrifice. People stuck in legacy codebases might want to apply or improve on Ironclad, though.

http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf

https://github.com/crdelozier/ironclad

[duneroadrunner]

Not my area of expertise, but a little googling yields:

"SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1]

As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. SaferCPlusPlus just introduces a memory-safe subset of C++ as an option. But a subset that doesn't require the re-architecting of existing C/C++ code as it provides safe compatible substitutes for C/C++'s unsafe elements.

> People stuck in legacy codebases might want to apply or improve on Ironclad, though.

SaferCPlusPlus only exists because Ironclad was/is not a practical solution. In particular because Ironclad is abandonware. In my opinion, Ironclad was a brilliant and impressive solution. SaferCPlusPlus strives to be a solution in the same vein, but one that takes advantage of modern C++ in its implementation. The non-viability of Ironclad exposed key problems shared with many other approaches. Namely, portability and, more importantly, dependency risk. SaferCPlusPlus is just a simple open source library written in pure, portable C++. It works on any platform with a reasonably modern C++ compiler. If you adopt it and at some point in the future it becomes abandonware, there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. And the library is simple enough that it should be fairly easy to add new features or customizations as needed.

[1] https://www.semanticscholar.org/paper/Performance-of-Compile...

[nickpsecurity]

re SAFEcode/Softbound. That's horrific vs the initial numbers. Good that they dug in to find most of it was in the bookkeeping. Work there might greatly reduce the overhead. That MPX is a Softbound-like scheme with hardware extensions for bookkeeping is already hopeful. Author needs to port it to MPX. Paper also mentions Ironclad C++.

"SaferCPlusPlus just introduces a memory-safe subset of C++ as an option."

True. This has at least basic benefit.

" Namely, portability and, more importantly, dependency risk."

What was the portability issue?

"there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. "

This would be a good selling point to enterprise customers or large FOSS projects that use C++.

[duneroadrunner]

One of the sanitizer guys tested the mpx instructions on skylake [1]. Tl;dr - Kind of underwhelming. But then, skylake is just the first iteration.

> What was the portability issue?

Oh, it was a long time ago that I investigated it and I don't remember the details very clearly, but for one, I needed a solution that supported Windows. Either it didn't support Windows, or its support for Windows was obsolete or something. I don't really remember. And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not. Yeah, I don't really remember the details, but it wasn't my intention to develop SaferCPlusPlus. If I could've gotten Ironclad to work for me, I probably would've been happy with that.

> This would be a good selling point to enterprise customers

Yeah, unfortunately I'm not selling anything, otherwise there would be marketing budget :)

[1] https://github.com/google/sanitizers/wiki/AddressSanitizerIn...

[nickpsecurity]

I didn't realize you developed SaferCPlusPlus or that it was an actual thing. I don't follow C++ anymore past what I see in a few forums. I mistakenly thought you were referring to attempts at standardization of safer stuff that they were calling Safer C++ or something in prior articles. So, you actually learned from projects like Ironclad then tried to do it simpler and better in your own project that you coded up. Great attitude and work!

"And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not."

My plan was to get some academics with an appreciation for making money to dig into it for non-sense like that, test its mechanisms, clean it up, and put in a concurrent, low-latency scheme for dynamic stuff. Then test it against common compilers and FOSS codebases before marketing it to companies to get some safety in various apps. :)

Of course, I have limited influence in current condition and you have no marketing budget for yours. Progress on Great Change stalls once again. Least you're keeping at your own project that might turn into something later.