Embedded software is used in safety-critical systems such as medical devices and autonomous vehicles, where software defects, including security vulnerabilities, have severe consequences. Most embedded codebases are developed in unsafe languages, specifically C/C++, and are riddled with memory safety vulnerabilities. To prevent such vulnerabilities, RUST, a performant memory-safe systems language, provides an optimal choice for developing embedded software. RUST interoperability enables developing RUST applications on top of existing C codebases. Despite this, even the most resourceful organizations continue to develop embedded software in C/C++.
This paper performs the first systematic study to holistically understand the current state and challenges of using RUST for embedded systems. Our study is organized across three research questions. We collected a dataset of 2,836 RUST embedded software spanning various categories and 5 Static Application Security Testing ( SAST) tools. We performed a systematic analysis of our dataset and surveys with 225 developers to investigate our research questions. We found that existing RUST software support is inadequate, SAST tools cannot handle certain features of RUST embedded software, resulting in failures, and the prevalence of advanced types in existing RUST software makes it challenging to engineer interoperable code. In addition, we found various challenges faced by developers in using RUST for embedded systems development.
↫ Ayushi Sharma, Shashank Sharma, Santiago Torres-Arias, Aravind Machiry
Some light reading.
While I more or less agree with the conclusion, it’s not a particularly robust paper, hasn’t been peer-reviewed and I spotted some sources that haven’t been peer-reviewed either.
It’s unfortunate that that most embedded software developers don’t consider using Ada. Ada is a very mature yet very modern and capable systems programming language. It scales well from very small to very large projects and can be easily interfaced with C or C++ code if needed. Ada also takes a broader view of memory safety than Rust does. Here is an overview of that: https://blog.adacore.com/memory-safety-in-ada-and-spark-through-language-features-and-tool-support
Sparky,
Could you elaborate on what you mean by “broader view of memory safety than Rust”? I know Ada type safety is superior to C, which didn’t even have proper range checking without the use of “lint” tools. C has single highhandedly cost society countless billions in damages and I agree Ada would have helped there, but to the best of my knowledge I don’t think static code verification back then was at the same level as Rust.
The article you linked to only references once and that’s when talking about spark as quoted below.
Were you referring to the new derivative spark language instead of the original Ada? If so that makes more sense to me. I wasn’t aware of Spark, and frankly I have more experience with pascal than Ada, but this is interesting.
https://learn.adacore.com/courses/intro-to-spark/chapters/01_Overview.html#what-is-it
No kidding. Ada was literally designed from the ground up with these use cases in mind.
Rust seems like awkward reinventing of the wheel. And once you want to use it for real time control stuff, you have to give up its only value proposition; memory management and thus you end up dealingw the same issues than C. So what is the point? And who makes up a programming language in the xxi century w objects as an after thought?
Rust has a very vocal community though.
Xanady Asem,
I don’t mean to dis Ada here, but I’m having trouble following the arguments here.
Here’s a quote from Sparky’s link…
I agree that rust is syntactically awkward. Even so I think they deserve a lot of credit for innovating with compile time memory safety.
What? Why would you have to give up rusts memory safety? It’s not a traditional safe language, the checks are verified by the compiler at compile time. That’s kind of rust’s whole deal.
I guess I am also having a hard time following your reply.
Memory safety is fairly common among many (most?) compiled/interpreted HLLs that use managed/automatic memory programming models.
Ada is a bit of an old language now, and honestly not my forte. I believe Ada also tries to be memory and thread safe by default. Variables allocated in the stack are automatically released once their scope exits. I believe variables on the heap have to be manually deallocated.
In any case, I think static analyzers like SPARK can also be applied to Ada?
I don’t know what you mean by “a traditional safe language?” A lot of compiled HLLs do the same type of bound checks at compile time.
Lastly; certain system and embedded programming use cases need deterministic memory access time patterns (think of the memory/page manager in an OS, or certain real time read/writes required in an embedded system). Raw pointers in rust allows to bypass the automatic memory management features and allow for more deterministic/fine grained control over memory access patterns. But then, you might as well just stick to C or even C++.
Honestly that is not my area of expertise. So I am just going by what some colleagues have relayed; rust has been of interest to them, but in many cases they either ended up sticking up to their C code base, or they didn’t see any major difference in safety from stuff they were already using like C# (which also gave them a object system by default).
I think Rust sits in that awkward middle ground; it’s safer than C but not as performant. But it’s not as rich in terms of programming model as other memory managed HLLs, so you might as well go with any of the new alternatives to C++ that seem to be popping up lately.
That being said. I think Linux is evaluating Rust. So it will be interesting how far they get with it. As that will obviously a much better benchmark in terms of how well suited it is for systems programming than my subjective rambling.
Xanady Asem,
Ada is not in my wheelhouse either, so I have to rely on links like the one OP posted.
I learned Pascal a long time ago, which is an Ada derivative and works the way you describe here. It was better than C for sure, the problem of course is those heap operations still are not safe, but in rust they are. Apparently the “Spark” language extensions makes the heap safe for Ada software too.
Sure I agree, but given that Spark was explicitly inspired by rust, do you agree it sounds harsh to accuse rust of “reinventing the wheel”?