4 ms·

> In conclusion, the empirical research supports the proposition that using memory-safe programming languages for these projects would result in a game-changing

by jmull 5y ago

> In conclusion, the empirical research supports the proposition that using memory-safe programming languages for these projects would result in a game-changing reduction in total number of vulnerabilities There are some missing pieces here. A software rewrite introduces a lot of new bugs. Take one of these OSs. They’ve been fixing security bugs for decades, ~30% of which are non-memory safety related. A rewrite in a truly memory safe language will have zero memory safety-related bug but will include a substantial number of new, non-memory-safety security bugs, the kind it took decades to remove from the original code. I think there would be a long term payoff, but considering the resources required, it’s unclear if a rewrite effort could even succeed at all. Realistically, you’re going to end up forking, with some development happening on a rewrite fork with low feature velocity and other development happening on a higher feature velocity fork with no rewrite effort. With low features and years with actually more security bugs, I’m not sure the rewrite fork would even survive. “using memory-safe programming languages for these projects” is easy to say, but what’s the actual path that can be followed from here to there?

AnimalMuppet 5y ago
What you say is true, and I'm not sure that "rewrite everything" is a valid approach. But if you're starting something today, you might take this data into account when choosing the language...
- ExtraE 5y ago
  Yes. I don't think rewrite everything was what the original author was arguing for, either.
  - AnimalMuppet 5y ago
    But someone will argue for it, so the warning not to is worthwhile.
pylua 5y ago
I principle I agree with this . However , if companies really believe there is zero tolerance for security issues , the only way forward is to, no matter the cost, proceed forward with a way that will minimize security problems. Otherwise we are just paying lip service to security .
- andi999 5y ago
  If you want zero security issues, probably Ada with spark is the way to go.
threatripper 5y ago
I don't quite agree with you. Rewriting software in general removes a lot of security related bugs because the new design is more clear. Of course some new ones will be introduced and need to be weeded out but I think those kind of bugs are the minority and can be weeded out in a fraction of the time it took for the original software. On the other hand it introduces a lot of usability bugs. Many things are they way they are because of many bug reports of many users that all have their own workflows and usage patterns. These kinds of bugs are harder to weed out. Also they can lead to early refusal by the users of the old software. Then there is the Version-2 effect of packing in too many new features and deliberately introducing fundamental changes that break everything at once. This, in my opinion, is the worst about a complete rewrite.
- jstimpfle 5y ago
  c.f. "Second System Effect". How many examples of successful rewrites of large systems can you come up with? The new design will only be better if there were actual lessons learned, which probably at least requires that it be done by the same people. Also, compared to incremental development I can attest that a big-bang rewrite takes a lot of grit to do all the grunt work again, replacing perfectly working and now rather boring infrastructure. It's very hard to suffer through it, even if some other parts could be substantially better.
  - btilly 5y ago
    Ironically the second system effect was named by Fred Brooks in The Mythical Man-Month. It is ironic because his background was heading development of a large, and ultimately successful, second system. Namely IBM's OS/360. Moving on, Brooks correctly identified that third systems do much better than second systems. (The pattern is that the first system suffers from your general incompetence, the second system tries to over-abstract and shove too many features in there, and the third system is the first where you can strike a pragmatic balance.) Still Mozilla/Firefox was a rewrite of Netscape, Python 3 a rewrite of Python 2, Doom a rewrite of Wolfenstein 3D, and so on. Many companies have a history of their third version of software being significantly better, meaning that they survived the first and second systems to get there. For example the first successful version of Windows was Windows 3.1. There is another kind of successful rewrite, which is a copycat product. For example MS Excel is a rewrite of Lotus 1-2-3 and Microsoft Word is a rewrite of WordPerfect. And, to keep this from just being picking on Microsoft, Google's Dalvik was a rewrite of the JVM. (And then Oracle sued...)
alkonaut 5y ago
“Using” memory safe languages as in selecting a language for green field projects vs “using” to mean “rewrite in” are two very different propositions. I don’t think many would consider rewriting a million line code base in a different language without other motivation than fixing memory safety. However all large code bases have some modularity and modules are added and rewritten. At that point the decision to use a different language is easier. That this now happens in Linux and elsewhere is a clear sign of the times.
Zababa 5y ago
That might be a very naive view of things, but can't you extract a test suite of the current system (including non-regression tests) to use it to develop the new system? Or do it part by part, ship of Theseus style?
- Const-me 5y ago
  Not sure that gonna work. Operating systems abstract away hardware differences, and providing portable APIs to userspace processes. Internally, OS kernels are spending non-trivial complexity dealing with random hardware shenanigans. Can't unit test them.
babatuba 5y ago
I totally agree with this sentiment. It is probably better to make robust code-quality software for scanning and eliminating these vulnerabilities. Taking C as an example, it is a simple language so probably also the easiest language in common low-level use to be able to parse and detect serious issues. The benefits to that are more advantageous given the sheer amount of code on systems.

by jmull 5y ago

AnimalMuppet 5y ago

What you say is true, and I'm not sure that "rewrite everything" is a valid approach. But if you're starting something today, you might take this data into account when choosing the language...

ExtraE 5y ago
Yes. I don't think rewrite everything was what the original author was arguing for, either.
- AnimalMuppet 5y ago
  But someone will argue for it, so the warning not to is worthwhile.

pylua 5y ago

I principle I agree with this . However , if companies really believe there is zero tolerance for security issues , the only way forward is to, no matter the cost, proceed forward with a way that will minimize security problems. Otherwise we are just paying lip service to security .

andi999 5y ago
If you want zero security issues, probably Ada with spark is the way to go.

threatripper 5y ago

I don't quite agree with you. Rewriting software in general removes a lot of security related bugs because the new design is more clear. Of course some new ones will be introduced and need to be weeded out but I think those kind of bugs are the minority and can be weeded out in a fraction of the time it took for the original software. On the other hand it introduces a lot of usability bugs. Many things are they way they are because of many bug reports of many users that all have their own workflows and usage patterns. These kinds of bugs are harder to weed out. Also they can lead to early refusal by the users of the old software. Then there is the Version-2 effect of packing in too many new features and deliberately introducing fundamental changes that break everything at once. This, in my opinion, is the worst about a complete rewrite.

jstimpfle 5y ago
c.f. "Second System Effect". How many examples of successful rewrites of large systems can you come up with? The new design will only be better if there were actual lessons learned, which probably at least requires that it be done by the same people. Also, compared to incremental development I can attest that a big-bang rewrite takes a lot of grit to do all the grunt work again, replacing perfectly working and now rather boring infrastructure. It's very hard to suffer through it, even if some other parts could be substantially better.
- btilly 5y ago
  Ironically the second system effect was named by Fred Brooks in The Mythical Man-Month. It is ironic because his background was heading development of a large, and ultimately successful, second system. Namely IBM's OS/360. Moving on, Brooks correctly identified that third systems do much better than second systems. (The pattern is that the first system suffers from your general incompetence, the second system tries to over-abstract and shove too many features in there, and the third system is the first where you can strike a pragmatic balance.) Still Mozilla/Firefox was a rewrite of Netscape, Python 3 a rewrite of Python 2, Doom a rewrite of Wolfenstein 3D, and so on. Many companies have a history of their third version of software being significantly better, meaning that they survived the first and second systems to get there. For example the first successful version of Windows was Windows 3.1. There is another kind of successful rewrite, which is a copycat product. For example MS Excel is a rewrite of Lotus 1-2-3 and Microsoft Word is a rewrite of WordPerfect. And, to keep this from just being picking on Microsoft, Google's Dalvik was a rewrite of the JVM. (And then Oracle sued...)

alkonaut 5y ago

“Using” memory safe languages as in selecting a language for green field projects vs “using” to mean “rewrite in” are two very different propositions. I don’t think many would consider rewriting a million line code base in a different language without other motivation than fixing memory safety. However all large code bases have some modularity and modules are added and rewritten. At that point the decision to use a different language is easier. That this now happens in Linux and elsewhere is a clear sign of the times.

Zababa 5y ago

That might be a very naive view of things, but can't you extract a test suite of the current system (including non-regression tests) to use it to develop the new system? Or do it part by part, ship of Theseus style?

Const-me 5y ago
Not sure that gonna work. Operating systems abstract away hardware differences, and providing portable APIs to userspace processes. Internally, OS kernels are spending non-trivial complexity dealing with random hardware shenanigans. Can't unit test them.

babatuba 5y ago

I totally agree with this sentiment. It is probably better to make robust code-quality software for scanning and eliminating these vulnerabilities. Taking C as an example, it is a simple language so probably also the easiest language in common low-level use to be able to parse and detect serious issues. The benefits to that are more advantageous given the sheer amount of code on systems.