The Move to Memory-Safe Programming

https://spectrum.ieee.org/memory-safe-programming-languages

by mfiguiere • 3 years ago

20 16 3 years ago

spectrum.ieee.org

You'd figure we would have treated SWE like other kinds of engineering and avoided the pitfalls of 2000 years of civil eng and 200 years of electrical eng, and yet here we are in 2023 where using at least static analysis is not the norm

agumonkey• 3 years ago

SWE tried to be like EE, but in a shallow way, that's what UML and components were in the early 2000s, an attempts at emulating EE. But not on laws and principles.. just on the representation.

timbit42• 3 years ago

We should have followed the path of the Wirthian language and Ada. I think part of the reason it wasn't followed is because Pascal wasn't as good as C, but Pascal was intended as a teaching language, not a real world language. Modula-2 was intended as a real world language but it was too late. There was a while in the 80's when Ada was more popular than C++ but only because of the DoD. The DoD, NASA and air traffic control systems still use Ada.

zafka2• 3 years ago

Just went to look to see if there were any complilers for Rust on Microchip or ST. Perhaps I have found a fun side project.

RealityVoid2• 3 years ago

STM32 are ARM based so you can build and run it today.

You have libraries and support for peripherals. I know TockOS has support for them.

zafka2• 3 years ago

Thanks, If I thought a bit before I typed I would have realized that. Most of my code the last 12 years has been C on dsPICs, but coworkers have been designing in ST micros recently. I am not very fond of the HAL system, but lots of folks seem to love it. I like setting all the registers myself.

nigrioid• 3 years ago

What's going to happen is an overconfidence in the absence of memory-related issues and an increase in the exploitation of other classes of bugs.

jjnoakes2• 3 years ago

I'm not so sure. If developers and testers and QA teams can spend less time on a class of issues, I imagine they'll have more time to spend on the other classes of issues, lowering their exploitability as well.

Hemospectrum• 3 years ago

Your phrasing suggests that this trend is wasteful and will not result in a net improvement in software security overall. The numbers suggest otherwise. Memory corruption exploits currently occur twice as often as all other classes of exploits combined, and disproportionately account for the most severe exploits in the relevant studies. Automating them out of existence means being able to spend more time and attention on everything else.

dataking• 3 years ago

... which is still a net win given that logic errors, AFAIK, take more effort to locate and exploit. (If someone has hard data that prove or disprove this, please share.)

viraptor• 3 years ago

That's not a great take in practice. The main example in the article is Rust and while they concentrate on the memory safety, modern languages which provide it also provide other great features. If we stick with Rust, we also get fewer concurrency issues (language enforced), logic issues (algebraic data types help), encoding issues (richer APIs help), etc.

Try to find a specific vulnerability class which actually has a chance of getting more likely if you move from C to Rust.

jstx1• 3 years ago

...started a long time ago when garbage collected languages became popular.

jjnoakes2• 3 years ago

...and is more recently making great inroads into places where garbage collectors (and other features of those popular languages) aren't desired.

waynecochran• 3 years ago

Demonstrates a lack of knowledge of Modern C++ when they lump C++ in with C. Modern C++ ain't anything like C anymore.

protastus• 3 years ago

Raw pointers are still common in modern C++ and those are of course not memory safe. Reasonable memory safety out of C++ would require rigorously adhering to a subset of the language, adding bounds checking to all containers, forbidding implicit type casting, etc.

The Move to Memory-Safe Programming

Related Stories