The Move to Memory-Safe Programming(spectrum.ieee.org)
spectrum.ieee.org
The Move to Memory-Safe Programming
https://spectrum.ieee.org/memory-safe-programming-languages
16 comments
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
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.
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.
Demonstrates a lack of knowledge of Modern C++ when they lump C++ in with C. Modern C++ ain't anything like C anymore.
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.
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.
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.
You have libraries and support for peripherals. I know TockOS has support for them.
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.
> I like setting all the registers myself.
I did as well, but once you write a low level driver for the nth time you kind of get sick of it and just want to build shit.
I was just playing with the very opposite of that idea recently actually, setting the peripheral configuration through a taylored bytecode. Should be portable, debuggable with the right infrastructure, statically analyzable and more easily external tool generatable. Maybe blasphemous for embedded programmers.
I did as well, but once you write a low level driver for the nth time you kind of get sick of it and just want to build shit.
I was just playing with the very opposite of that idea recently actually, setting the peripheral configuration through a taylored bytecode. Should be portable, debuggable with the right infrastructure, statically analyzable and more easily external tool generatable. Maybe blasphemous for embedded programmers.
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.
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.
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.
... 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.)
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.
Try to find a specific vulnerability class which actually has a chance of getting more likely if you move from C to Rust.