About Rust in embedded

[Marco]

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.

The fundamental problem is using a text API with foreign input, it's a huge security anti-pattern. Text APIs should only be for interactive/static use, everything else should be "compiled" and only accept string parameters with length, not null or white space terminated. SQL, shell, HTML, XML, format strings (printf). All never ending sources of exploits.

If you have to concat and escape, you will screw up in an easily exploited way. It's inevitable and frequent.

[nctnico]

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.

The fundamental problem is using a text API with foreign input, it's a huge security anti-pattern. Text APIs should only be for interactive/static use, everything else should be "compiled" and only accept string parameters with length, not null or white space terminated. SQL, shell, HTML, XML, format strings (printf). All never ending sources of exploits.

The problem is in sloppy programming. But it isn't limited to text. With binary data you can also have a variable length. In my software every function which works on variable length data, also receives the size of the buffer/array which receives the data AND checks whether the amount written into a buffer/array isn't exceeding the length. This has been hugely benificial to keep any problems localised, programs fail in a predictable way and thus make a bug easy to locate.

[janoc]

I wonder how many of you have actually tried to use Rust for embedded? I did, for ARM (STM32F1 & F4 series) because I liked the idea of built-in coroutines/async.

TL;DR - it is not mature enough.

But probably not because of what you think. The language itself is fine even though the extremely noisy syntax is an acquired taste and the constant battle with and having to bend over backwards at design stage to make the borrow checker happy feels wrong. When the tool dictates architecture or you will never get it to compile it is a problem. But I digress.  The documentation is also mostly OK and I am not missing vendor tooling - that one is almost universally crap. Give me vendor-independent compilers and tools any day.

The real problem embedded Rust is the ecosystem. Even for "desktop" Rust this is a problem, for embedded it is a complete showstopper. For languages like C, C++ or Python you are going to find millions of tools, libraries, etc. For Rust? Maybe one or two libraries solving the problem you need solved. For embedded it is even worse because Rust is a niche language - and embedded Rust is an even smaller niche within the niche.

The catch? They are mostly one-man projects, often last updated several years ago and not touched since because the author has lost interest and/or moved on to something else. So they don't work with the current compiler or require obsolete dependencies or (in the case of embedded Rust) don't work without the standard library or don't support the MCU you need to use it with ... In the best case, they are half-finished - and you discover that only after spending  hours trying to make some unimplemented feature work.

So unless you have nothing better to do with your time or are writing everything from scratch, including USB stacks and RTOSes as a matter of course, this is really not the tool you are looking for.

I am sure Rust fanboys will jump at me now with "But you can just use X!!!!", "But look at Y!!!", "But safety!" - but that's completely irrelevant. If the tool isn't solving my use case it is not the tool for the job. I need to get work done, I am not messing with it for fun or because I like this language over that one.

BTW, re code safety in Rust - that you have a borrow checker doesn't mean you won't crash your MCU or destroy your data. It merely prevents one class of bugs that other languages, even C, can avoid too, even though the developer needs to do more work and be more diligent in order to not shoot themselves in the foot. This Rust feature is likely one of the most overblown and misunderstood language features in history.

I am keeping an eye on Rust and periodically check on projects like https://embassy.dev/ hoping that things get better supported but I am still writing most of my code in C, C++ and Python instead.

[Marco]

also receives the size of the buffer which receives the data.

Yet that is precisely what is not possible with text based interfaces. They will always rely on in band special characters and people will always keep screwing that up in easily exploited ways.

[tggzzz]

The language itself is fine even though the extremely noisy syntax is an acquired taste and the constant battle with and having to bend over backwards at design stage to make the borrow checker happy feels wrong. When the tool dictates architecture or you will never get it to compile it is a problem.

Isn't that the wrong way round?

The consequences of aliasing plus modern multicore/processors plus cache/NUMA architectures makes the "ownership" of a piece of data a key design choice. That choice is enforced by the language.

There is an equivalent constraint with xC, and it solves it by forbidding aliasing.

[nctnico]

also receives the size of the buffer which receives the data.

Yet that is precisely what is not possible with text based interfaces. They will always rely on in band special characters and people will always keep screwing that up in easily exploited ways.

The same is true for any kind of variable length data. You'll need some kind of delimiter one way or another and verification whether the length matches the delimiter. So either way you need to do sanity checks. But these are relatively easy to implement for as long as you use the length of the local buffer as a safeguard against processing 'bad' data.

[josfemova]

I am sure Rust fanboys will jump at me now with "But you can just use X!!!!", "But look at Y!!!", "But safety!" - but that's completely irrelevant. If the tool isn't solving my use case it is not the tool for the job. I need to get work done, I am not messing with it for fun or because I like this language over that one.

As the proverbial fanboy on this thread I'm sorry, I have to jump at you now, I'm don't have a choice, they have my family at gun point.
Being a little bit more serious, your criticism is actually one of the few that's actually fair. The ecosystem is not mature enough and as you point out there are use cases in which there are diminishing returns or limited benefits once you compare what you get vs what you loose. At the moment, for serious, complex projects that need to run on the metal you are better served by something like Zephyr and for botching Arduino/Python is all you need. Then again, some serious projects do use Rust but as you pointed out, they are owners of almost all components in their codebase (I'm talking about Oxide Computer here)

BTW, re code safety in Rust - that you have a borrow checker doesn't mean you won't crash your MCU or destroy your data. It merely prevents one class of bugs that other languages, even C, can avoid too, even though the developer needs to do more work and be more diligent in order to not shoot themselves in the foot. This Rust feature is likely one of the most overblown and misunderstood language features in history.

Agree. I think I like the Borrow Checker during the design/PoC phase because it forces some questions that might get you bit in the ass if you either ignore them or try to botch them, but the borrow checker is not a silver bullet and you can still have undesirable behavior in a Rust program that is not considered unsafe (e.g. deadlocking is safe) more info https://doc.rust-lang.org/reference/behavior-not-considered-unsafe.html

I am keeping an eye on Rust and periodically check on projects like https://embassy.dev/ hoping that things get better supported but I am still writing most of my code in C, C++ and Python instead.

I'm currently revisiting this and the ecosystem in general. It's getting better and the embedded-hal/embedded-io changes make writing stuff less cumbersome. I have some STMs at hand but ESP32s seem the way to go as they are the only ones with official vendor support, luckily I also have a bunch of them. Easy async programming in embedded it's very attractive for many use cases, especially for IoT devices that must be responsive. Still not as easy as opening circuitpython for a botch tho'

[Marco]

The same is true for any kind of variable length data.

Only when out of band communication is impossible. Mostly compression formats and wire protocols by necessity and text interfaces by convenience (strictly speaking it's still possible to include lengths, but then it's not really human editable any more). Also null ended strings by stupidity. The moment OoB communication is possible you can just include the length.

For humans it's provably not easy to get escaping right ... injection is right up there with memory related bugs as a cause for exploits.

[SiliconWizard]

It's a simple parsing error. It's a common bug that will never be eradicated by any programming language.

The fundamental problem is using a text API with foreign input, it's a huge security anti-pattern. Text APIs should only be for interactive/static use, everything else should be "compiled" and only accept string parameters with length, not null or white space terminated. SQL, shell, HTML, XML, format strings (printf). All never ending sources of exploits.

The problem is in sloppy programming. But it isn't limited to text. With binary data you can also have a variable length. In my software every function which works on variable length data, also receives the size of the buffer/array which receives the data AND checks whether the amount written into a buffer/array isn't exceeding the length. This has been hugely benificial to keep any problems localised, programs fail in a predictable way and thus make a bug easy to locate.

This is down to input validation more generally speaking (lack thereof), and the number 1 issue in software IMO. *This*, to me, should be absolute priority to make things more robust and more secure, and apart from Ada / Spark and very, very few languages that have integrated the concept of "contracts", I don't see anything much done to help with that, and so it's going to come and bite us, over, over and over again, be it with Rust or Dreamberd.

[Marco]

This is down to input validation more generally speaking (lack thereof), and the number 1 issue in software IMO. *This*, to me, should be absolute priority to make things more robust and more secure, and apart from Ada / Spark and very, very few languages that have integrated the concept of "contracts", I don't see anything much done to help with that, and so it's going to come and bite us, over, over and over again, be it with Rust or Dreamberd.

Escaping/de-escaping across multiple text formats and program stages is not as trivial as people pretend ... it won't even be immediately obvious what and how to validate/sanitize at any given point in the program.

The way we use text makes the program too hard to reason about ... so don't use text like that. SQL is wrong. HTML is wrong. XML is wrong. Printf is wrong ... and in this case cmd is wrong. Parameters should be passed in as an array of strings with length, no character in those strings should be able to cause an injection exploit by spreading to a different command than intended.

Almost all code should take strings+length from top to bottom.

PS. practically that means that editors should add length automagically to colour coded parameter strings for a safe version of HTML/XML (no more need for base64, that alone would easily be worth it looking like garbage in Vi, human readability of the lowest level representation in plain text is ridiculously overvalued). SQL/cmd, where you can with relative ease call them as a function, can in theory suffice to just have the interpreter only take strings+length as external parameters and leave making sure they can't leak to the interpreter.

You will have to beat web programmers around the head a lot for them to stop just concatenating SQL themselves, three decades of SQL injection hasn't managed.