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

131–140 of 159 posts

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

#131

Post by reaperman »

steveklabnik wrote: post #70
bigyikes wrote: post #61

Earlier quoted context omitted.

Is video game security an entire subfield of its own? I imagine there are categories of exploits in video games which simply don’t exist in other areas of software

The latest in FPS cheating (that I'm aware of, not like I'm super plugged into the underground) involves buying a second PC to run the cheats, a card for your main PC to grab a copy of memory over DMA, ship it off to the second PC, then joining the two video feeds together. Apparently you can also hook your mouse up to a connection where it will edit the data flowing from the mouse to give you better aim as well. A l…

The "end-game" for cheating software is just a camera pointed at the monitor, or an HDMI splitter. Run the video feed through a not-invented-yet AI/ML model, and the model will control your character via valid USB keyboard/mouse inputs.

"Behavioral" anti-cheat will have to finally become a thing. As a game designer in 5-10 years, you won't be able to assume the operating system will be privy to any data which indicates cheating is happening.

I believe the right answer would be to cluster players by behavior signatures, leading to all the bots being in clusters with eachother. Then bots can mostly just play other bots. Over time you can merge known "human" clusters together so that different play styles get to play in the same matches. This also has the benefit of clustering "toxic" players together - both by chat content and in-game player behavior.

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

#132

Post by palata »

troad wrote: post #116
palata wrote: post #68

Earlier quoted context omitted.

> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.

I'm somewhat puzzled - the obvious answer is that you don't have to use them. Rust by itself is no less feature complete than C. Anything you can write in C without dependencies, you can write in Rust without dependencies too. Of course, dependency-reliance falls on a spectrum for any individual programmer. On the one hand you have script kiddies with 400 npm dependencies gathered from arcane Discord channels - on th…

> I'm somewhat puzzled

Because you find it fine to say that "people dramatically overestimate the correctness of their [C/C++] code", but not fine to say that "people tend to depend on too many third-parties that they never question"?

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

#133

Post by DannyBee »

otabdeveloper4 wrote: post #120
AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

Memory safety issues don't matter. There are five orders of magnitude more pwned boxes due to misquoted strings then there are due to memory safety issues. You are searching for a problem that could potentially make Rust useful instead of solving a real existing problem that people actually have.

So I think rust is maybe not the right hammer, but the first part is definitely wrong.

I'm not sure where your data comes from, but memory safety issues are roughly 50% of all exploitable security vulnerabilities.

They were also about 50% of all crashes of android apps (null pointer exceptions)

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

#134

Post by palata »

_w1tm wrote: post #126
palata wrote: post #68

Earlier quoted context omitted.

> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.

> At least in C/C++ it's much harder to get there. Interesting take. Poor package management as a security feature. As others have pointed out, instead of potentially poorly written third-party dependencies C/C++ will just have potentially poorly written homebrew replacements.

> Interesting take. Poor package management as a security feature.

How poor is it to install a package with your system package manager instead of the language package manager? I wouldn't call it poor.

The biggest difference I see is that language package managers are usually not curated (and that's a feature: "it's much faster than getting your package accepted in a distro").

My preference is to rely on curated package managers when I can. When I can't, then I am the maintainer, and therefore I need to handle the dependencies myself. You can call it "poor", but the fact that I maintain my dependencies is actually a security feature. When you depend on 600 third parties that you don't even know and that are not curated, it is a security problem.

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

#135

Post by palata »

rendaw wrote: post #118
palata wrote: post #92

Earlier quoted context omitted.

So if you have 200 dependencies, you trust them just because they don't run what Rust calls "unsafe" code? What about safe code that could be malware?

Isn't this hierarchical trust? You select immediate dependencies that you believe are written by reasonably security-conscious people, not just anything that immediately solves a problem, and because they're reasonably security-conscious people they select their own dependencies the same way? And at each level vetting is implicitly shared with other users of the dependencies, some of whom will be more critical/inquis…

That's the thing about trust: not everyone uses it the same. There are documented examples of malware being injected to millions of dependents through package managers, so we know that "hierarchical trust" does not work.

The big difference with a distro is that I choose to trust the distro maintainers, which is only a handful of people. Whereas with your hierarchical trust, you choose to trust many random people.

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

#136

Post by palata »

GrumpySloth wrote: post #114
meragrin_ wrote: post #109

Earlier quoted context omitted.

So what in there guarantees I can get the same thing they audited?

Version numbers. You can’t modify an already-published version of a Rust crate on crates.io.

Who in practice pins their dependencies (transitive included) on audited versions?

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

#137

Post by otabdeveloper4 »

DannyBee wrote: post #133
otabdeveloper4 wrote: post #120

Earlier quoted context omitted.

Memory safety issues don't matter. There are five orders of magnitude more pwned boxes due to misquoted strings then there are due to memory safety issues. You are searching for a problem that could potentially make Rust useful instead of solving a real existing problem that people actually have.

So I think rust is maybe not the right hammer, but the first part is definitely wrong. I'm not sure where your data comes from, but memory safety issues are roughly 50% of all exploitable security vulnerabilities. They were also about 50% of all crashes of android apps (null pointer exceptions)

Android apps are written in Java and Java is a memory safe language like Rust.

(Null pointer exceptions are a logic error, not a memory error.)

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

#138

Post by steveklabnik »

reaperman wrote: post #131
steveklabnik wrote: post #70

Earlier quoted context omitted.

The latest in FPS cheating (that I'm aware of, not like I'm super plugged into the underground) involves buying a second PC to run the cheats, a card for your main PC to grab a copy of memory over DMA, ship it off to the second PC, then joining the two video feeds together. Apparently you can also hook your mouse up to a connection where it will edit the data flowing from the mouse to give you better aim as well. A l…

The "end-game" for cheating software is just a camera pointed at the monitor, or an HDMI splitter. Run the video feed through a not-invented-yet AI/ML model, and the model will control your character via valid USB keyboard/mouse inputs. "Behavioral" anti-cheat will have to finally become a thing. As a game designer in 5-10 years, you won't be able to assume the operating system will be privy to any data which indicat…

Right, what I'm describing is basically 90% of that setup, just copying memory rather than with a camera.

> leading to all the bots being in clusters with eachother.

Some games do this! The factors are different, but yeah.

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

#139

Post by MSFT_Edging »

yeeeloit wrote: post #81
MSFT_Edging wrote: post #41

Earlier quoted context omitted.

> connect it to a popular OLED display? At least for the ssd1306 and the sh1106 there is in fact a library for it that works well. I recently started working on a rust-esp32 project because I'm far too lazy to properly deal with json in C. It was basic, some buttons, a display, an encoder, and a web api but it was a breeze. I'd really like to continue on more complex projects in the future. I've somehow avoided writi…

Why do you think you might have to go back and to C++?

Industry is firmly in C/C++ land and I'm trying to pivot towards a more embedded career, which would put me in more junior jobs without the political sway to say "lets try embedded rust and contribute back".

There's a couple forward thinking companies like memfault, but it seems to be the minority.

My degree was in CE so I've always played around with embedded projects, but actual design skills have stagnated from being in my field, which trends towards only developing smaller purpose built tools for internal use over products.

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

#140

Post by jnxx »

palata wrote: post #68
AlotOfReading wrote: post #7

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of fail…

> People dramatically overestimate the correctness of their [C/C++] code Genuinely interested: what do people think of their tons of third-party dependencies in Rust? My experience building Rust projects is that there are orders of magnitudes more dependencies than what would make me comfortable. At least in C/C++ it's much harder to get there.

> Genuinely interested: what do people think of their tons of third-party dependencies in Rust?

Here are three things I think, and they have in fact nothing to do with Rust:

1. The easier it is to add dependencies, the more dependencies will be added on average - unless you work purposefully against that.

2. The effect of a rising average number of dependencies in libraries is that their number of dependencies grows as well, and the number of their dependencies' dependencies... up to dependency graphs of several hundred nodes size. Like in exponential growth. An example would be the dependency graph of jquery.

3. I observe this "exponential" growth can have chain-reaction-like effects, like if you have a mass of U235 that achieves critical mass. Below that critical value, some neutrons flying around might trigger a few fissions, but these die out. Above that value, neutrons lead to fissions which lead to more neutrons and so on. The same can happen with complexity in multi-component software. At some point, complexity goes through the roof.

And the latter is especially true if backwards compatibility is not strictly observed, since backwards-incompatible changes tend to be infectuous in that they often make their client components (parents in the dependency graph) backwards-incompatible as well, in other words, there is breakage that propagates up the dependency graph. That breakage might die out and be able to be contained by local fixes, or it might propagate. And once your dependency graph becomes large enough, it is almost guaranteed, that you have breakage.

All these things together is why I believe that systems like NixOS or Guix are the future (but of course there might be other developments in that space).

Post reply on HN