The post could be summed up as use memory-safe languages because they’re better at not introducing vulnerabilities that involve memory manipulation. Most people coding in C or C++ know that. We can only win so many of them over talking safety. We might be better off talking about benefits such as easier to build large programs, catch more kinds of errors (esp temporal or races in Rust), super-easy to call existing C code, and so on with specific alternatives. Yet, C and C++ both have a lot of tooling to back them to smooth over some of their rough edges. We’ll probably need more examples of realistic code showing how these languages make it easier to accomplish the users’ goals on top of the safety benefits. An example is Wirth-style languages compiling really fast for quick iterations. I was told D, a C++ alternative, was quick too.
Now, the other problem is that many won’t transition from C or C++. That will be true for critical projects. So, we need tools and methods to do what you described: knock out as many vulnerabilities as possible before the code even runs. We also need a reference sheet for stuff like that. That might have guidelines for safe/secure coding, tools that enforce that highlighting deviations at the least, libraries for reference counting, libraries for safer operations, a list of static analyzers, design-by-contract combined with property-based testing like theft, and fuzz testers. Maybe some runtimes to use during testing that can catch problems a la dynamic analysis. Remember that most high-assurance software is written in C language. It’s clearly doable with right restrictions, tool support, and most of all time and focus on QA.
That folks rarely have the time for the latter is probably our strongest argument in favor of efficient, memory-safe languages. They’ll miss something. Better that the result of that not be critical. But, if they want to ignore our recommendation, we have these other recommendations for C and C++ that improve its security as shown in (examples here).
As an example, I just submitted the write-up on Mars Code done in C:
Yeah, best thing to do these days is just generate C. There’s just been so much work on the C compilers it’s doubtful any other languages’ compilers will catch up soon. If you’re looking at stuff for C safety, I’ll just drop what links I can remember on that topic. There sadly haven’t been many that were worth remembering. Here’s four in one survey paper:
Lastly, there was Clay that one team built and Lea Wittie kept building things on. It’s a C-like language with dependent types (esp linear) for memory safety, pre/post conditions for other checks, and outputs C++ for some reason instead of C. The Laddie thing for drivers I just submitted extracts to Clay.
The post could be summed up as use memory-safe languages because they’re better at not introducing vulnerabilities that involve memory manipulation. Most people coding in C or C++ know that. We can only win so many of them over talking safety. We might be better off talking about benefits such as easier to build large programs, catch more kinds of errors (esp temporal or races in Rust), super-easy to call existing C code, and so on with specific alternatives. Yet, C and C++ both have a lot of tooling to back them to smooth over some of their rough edges. We’ll probably need more examples of realistic code showing how these languages make it easier to accomplish the users’ goals on top of the safety benefits. An example is Wirth-style languages compiling really fast for quick iterations. I was told D, a C++ alternative, was quick too.
Now, the other problem is that many won’t transition from C or C++. That will be true for critical projects. So, we need tools and methods to do what you described: knock out as many vulnerabilities as possible before the code even runs. We also need a reference sheet for stuff like that. That might have guidelines for safe/secure coding, tools that enforce that highlighting deviations at the least, libraries for reference counting, libraries for safer operations, a list of static analyzers, design-by-contract combined with property-based testing like theft, and fuzz testers. Maybe some runtimes to use during testing that can catch problems a la dynamic analysis. Remember that most high-assurance software is written in C language. It’s clearly doable with right restrictions, tool support, and most of all time and focus on QA.
That folks rarely have the time for the latter is probably our strongest argument in favor of efficient, memory-safe languages. They’ll miss something. Better that the result of that not be critical. But, if they want to ignore our recommendation, we have these other recommendations for C and C++ that improve its security as shown in (examples here).
As an example, I just submitted the write-up on Mars Code done in C:
https://lobste.rs/s/it3pd0/mars_code_building_robust_software_2012
checked C from microsoft research really interested me, but i was disappointed it was a fork of clang instead of just a compiling to regular C.
Yeah, best thing to do these days is just generate C. There’s just been so much work on the C compilers it’s doubtful any other languages’ compilers will catch up soon. If you’re looking at stuff for C safety, I’ll just drop what links I can remember on that topic. There sadly haven’t been many that were worth remembering. Here’s four in one survey paper:
https://www.cs.uic.edu/pub/Main/PhDQualifyingExam/Sample4.pdf
One of the Cyclone people dusted it off maybe in a form for people to try out:
http://trevorjim.com/unfrozen-cyclone/
Lastly, there was Clay that one team built and Lea Wittie kept building things on. It’s a C-like language with dependent types (esp linear) for memory safety, pre/post conditions for other checks, and outputs C++ for some reason instead of C. The Laddie thing for drivers I just submitted extracts to Clay.
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C415FA6A08DD59EBB5C0825D0F229AE1?doi=10.1.1.490.8573&rep=rep1&type=pdf
https://www.eg.bucknell.edu/~lwittie/research.html
Have fun with those.