[duneroadrunner]

SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[nickpsecurity]

I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used.

All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.

[duneroadrunner]

SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to build firefox using them, but they couldn't successfully build it [1].

Perhaps nobody cared to address the C/C++ (memory) safety problems when the solutions required significant compromise. But the santizers are now (or could be with a little effort) a much more practical "no code modification required" solution than the previous options. And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives.

Maybe these new and improved choices will make a difference. We can dream, can't we? :)

[1] https://blog.torproject.org/category/tags/tbb-hardened

[mSparks]

"Safe/Secure" code - by definition must be slower than unsafe code.

Because every operation must pass over a series of hurdles to make sure it is safe. - does the code have permission to do this, is everything being supplied within bounds, is the system in a stable state.

Every language is about the same with all these checks in place. In fact C is quite possibly slower, because so many of the memory jumps will be so far away, and compilers are much better at optimising for this than people.

In my opinion not having these checks is only acceptable when the permissions of all developers and all users - potential and actual are identical. While there are rare cases this is true, much to many developers chargrin, in nearly every case it is not.

The whole point of SSL is that developers, users and users of the users permissions are totally different.

[DasIch]

This isn't true at all. The language has an impact on whether you can make perform these checks at runtime or at compile time. If you can do them at compile time, performance isn't affected at all and the code won't run slower.

[nickpsecurity]

"If you can do them at compile time, performance isn't affected at all and the code won't run slower."

That's not universally true. Compiler people tell me some optimizations happen using undefined behavior. Personal experience shows some, esp hand-optimized assembly, rely on stuff that a static analyzer just couldn't handle. These are common in compression, encryption, and multimedia libraries. So, you indeed might sacrifice performance writing code in a language that can knock out all kinds of problems at compile time working within the coding style it needs to do that.

In the general case, though, your point holds so far as lots of problems can be knocked out at compile time without affecting performance enough for the user to care.

[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...

[pjmlp]

I doubt anyone in C community would turn them on anyway.

They even made the "security" annex optional in C11!

[duneroadrunner]

Well that's just it, use of the sanitizers is not up to the developers, it's a build-time option. The TOR guys have enabled them when building firefox[1]. But apparently some of their debugging features actually introduce potential vulnerabilities themselves so they're not really appropriate for deployed executables. Yet.

[1] https://blog.torproject.org/category/tags/tbb-hardened