Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for Embedded Systems: Current state, challenges and open problems

arxiv.org

Post reply on HN
Print view View original

51–60 of 159 posts

Re: Rust for Embedded Systems: Current state, challenges and open problems

#51

Post by NoboruWataya »

fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

> 1. https://arewertosyet.com/ to track rust RTOSes and their status

As an aside, does anyone know if there is a central directory of these Rust "areweXyet" websites? I didn't know of this one but I knew about https://areweideyet.com/ and https://areweguiyet.com/

Re: Rust for Embedded Systems: Current state, challenges and open problems

#52

Post by hgs3 »

throwaway17_17 wrote: post #25

The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder a…

Correct me if I'm wrong, but the percentages on page 25 are lower then what you listed?

Out of Bounds Reads => 10.1%;

Out of Bounds Writes => 34%;

Null-Ptr Deref => 4.6%;

Type Confusion => 0.9%

Uninitialized Pointer Access => 0.9%

Use-After-Free => 2.8%;

Memory Leaks => 0.9%;

The most staggering statistic is the out of bounds writes. C23 added variably-modified types which helps [1], but I hope future revisions of C consider adding slices. I quite like Zig slices where a "slice" can be constructed from any pointer+length pair.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf

Re: Rust for Embedded Systems: Current state, challenges and open problems

#53

Post by petsfed »

sitzkrieg wrote: post #22
Aurornis wrote: post #18

Earlier quoted context omitted.

> 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). There are a lot of obscure MCU families out there. Most engineers or shops specialize in a couple, become familiar with those, and stick to it. Using and learning a brand new MCU family is a lot of work. As long as I can find Rust support for common MCUs that I use, I don’t care how broadly the rest of the market is c…

hope that mcu never goes on backorder :-)

It would need to be an historic backorder to make me switch from e.g. STM32 to like a C2000. Or honestly from an STM32F to STM32H.

For those how don't know, its very rare for a production device to use a socket for its MCU. Most MCUs don't even come in packages that support sockets. They're always soldered in. So unless you're switching to another MCU whose pinout, external clock, and power supply requirements are close enough that the hardware change is really just a BOM change, switching MCUs in case of a shortage is not a realistic option. Reportedly, some manufacturers were buying entire washing machines during the height of the chip shortage, just to de-solder the machines' MCUs and use them in their own products. That that is the better option should tell you how painful changing MCUs can be.

And that's to say nothing about porting the firmware, which may, or may not, be trivial.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#54

Post by jandrese »

jcranmer wrote: post #12
fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

> 2. there are tools to convert c to rust (I dont know if I'd trust this..) The core C specification by itself isn't all that complicated of a language; a C-to-Rust transpiler is a pretty doable project. The main issues here are that a) a lot of the code you'd likely want to convert is likely to be reliant on non-standard extensions b) there's a lot of undefined behavior which you probably want to have somewhat more…

The big problem is just the fundamental mismatch between what Rust requires and what you can do in C, especially with embedded code.

If the library in question handles interrupts by jumping to an interrupt handler that updates some shared state you're going to have a bad time converting that into safe Rust.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#55

Post by toast0 »

hajile wrote: post #44
outworlder wrote: post #34

Earlier quoted context omitted.

That's good when it's just about memory leaks. Your missile guidance code can have leaks as long as the missile completes the mission, since it will all be... "garbage collected" anyway. It's not great when you have problems like use after free and pointers going to where they don't belong. Those can cause security vulnerabilities that rebooting won't fix.

Then they make a version that flies farther and it sometimes randomly fails to detonate.

So you write a note mentioning there's a leak, and debug it if there's a need for it.

Finding a bug doesn't mean you need to fix it, or fix it right away. Using Rust doesn't preclude resource leaks. I'm pretty sure I've managed to run into resource leaks in all of the languages I've used in production, doesn't matter if they were managed or not. Sometimes limiting the lifetime of the thing that holds resources, and let process (or system) death clean it up works great; sometimes that's terrible, depends on the cost of death/restart, the lifetime between deaths, human intervention required, accuracy of lifetime estimation method, probably some other things. I don't worry too much about leaks that require a restart every year or so; nor would I worry about a leak in a missile that will cause issues beyond the achievable maximum flight time.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#56

Post by throwaway17_17 »

hgs3 wrote: post #52
throwaway17_17 wrote: post #25

The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder a…

Correct me if I'm wrong, but the percentages on page 25 are lower then what you listed? Out of Bounds Reads => 10.1%; Out of Bounds Writes => 34%; Null-Ptr Deref => 4.6%; Type Confusion => 0.9% Uninitialized Pointer Access => 0.9% Use-After-Free => 2.8%; Memory Leaks => 0.9%; The most staggering statistic is the out of bounds writes. C23 added variably-modified types which helps [1], but I hope future revisions of C…

The stats you listed are for the percentage of CVE causes out of the total reviewed CVEs (109), which includes those CVE causes Rust can prevent and those that are completely language independent causes. I took the stats for those CVEs that Rust is said to prevent, which according to the paper is 59 CVEs. So I took the number of any given cause and took its percentage out of the 59 CVEs that Rust's memory safety guarantees would prevent.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#57

Post by almatabata »

logicchains wrote: post #39
marcosdumay wrote: post #31

Earlier quoted context omitted.

The C and C++ ecosystems are suffering from a selection effect, in that the people that have any concern about their code being correct are trying to drop them, while the people comfortable with the language are all the ones that don't know about the problems. I expect the careless unaware culture to get worse with time as more and more aware people manage to leave it.

>the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).

> Or the ones writing code where security doesn't matter, like HFT and video games

A lot of games have a multiplayer mode nowadays, that opens it up for exploits. I do not want to get my PC hacked because I connected to a game server. If you mean only single player offline games, I guess yes security is less of an issue.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#58

Post by amlozano »

logicchains wrote: post #39
marcosdumay wrote: post #31

Earlier quoted context omitted.

The C and C++ ecosystems are suffering from a selection effect, in that the people that have any concern about their code being correct are trying to drop them, while the people comfortable with the language are all the ones that don't know about the problems. I expect the careless unaware culture to get worse with time as more and more aware people manage to leave it.

>the people comfortable with the language are all the ones that don't know about the problems. Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).

Complicated video games, especially ones with transactions or multi-player aspects, require a lot more security code than you might expect.

Re: Rust for Embedded Systems: Current state, challenges and open problems

#59

Post by Animats »

jcranmer wrote: post #12
fusslo wrote: post #5

my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integratin…

> 2. there are tools to convert c to rust (I dont know if I'd trust this..) The core C specification by itself isn't all that complicated of a language; a C-to-Rust transpiler is a pretty doable project. The main issues here are that a) a lot of the code you'd likely want to convert is likely to be reliant on non-standard extensions b) there's a lot of undefined behavior which you probably want to have somewhat more…

> C-to-Rust transpiler is a pretty doable project.

It's been done, but what comes out is terrible Rust. Everything is unsafe types with C semantics.

An intelligent C to Rust translator would be a big win. You'd need to annotate the input C with info about how long arrays are and such, to guide the translator. It might be possible to use an LLM to analyze the code and provide annotations. Usually, C code does have array length info; it's just not in a form that the language ties to the array itself. If you see

    char* buf = malloc(len);
the programmer knows that "buf" has length "len", but the programmer does not. Something needs to annotate "buf" with that info so that the translator knows it. Then the translator can generate Rust:

    let mut buf = vec![0;len];
The payoff comes at calls. C code:

    int write_to_device(char* buf, size_t len)
is a common idiom. LLMs are good at idioms. At this point, one can guess that this is equivalent to

    fn write_to_device(buf: &[u8]) -> i32
in Rust. Then the translator has to track "len" to make sure that

    assert_eq!(buf.len(), len);
is either provably true, or put in that assert to check it at run time. So that's a path to translation into safe Rust.

Funding could probably be obtained from Homeland Security for this, given the new White House level interest in safe languages and the headaches being caused by the cyber war. Is CVS still down?

Re: Rust for Embedded Systems: Current state, challenges and open problems

#60

Post by xyst »

tamimio wrote: post #26

Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.

What’s wrong with wrapping the C headers in rust?

Seems possible to me, although a bit labor intensive depending on the C/C++ lib — https://docs.rust-embedded.org/book/interoperability/c-with-...

Post reply on HN