-
A government decree won't stop corporations from churning out shit software or half-finished hardware.
This is the main cause of security issues.
Changing languages will not fix it. -
It depends what you are programming. A lot of small embedded processors are doing endless manipulation of peripherals. However, what you say is true for most larger embedded programs. You really ought to make life as easy as possible on the bulk of the code, so you have more time to put more focus of the gritty stuff.
Even most embedded things that do "endless peripheral manipulation" generally don't have (or at least don't need) a tremendously large number of lines of code actually accessing the registers. I doubt very many even small projects would need a tremendous fraction of their code to be marked unsafe. Write a handful of GPIO helpers that use unsafe code and all the code that calls them can be safe, etc.
That said, embedded systems design practices often have already solved the problems that memory safe languages address. If you don't use dynamic allocation a huge class of errors go away. If you make minimal use of arrays and pointer arithmetic, and don't pass array pointers to functions that don't have their size visible, another big chunk go away. There is even some use (and yes, also misuse) of formal proofs. If you can prove that you never access your statically allocated arrays out-of-bounds, that fixes yet another set of bugs. So I agree that in some embedded situations the benefits of a memory safe language may be kind of moot. Not because they are a bad idea, but because they already have much more draconian rules on memory use than you could tolerate in a more general purpose system. -
A government decree (...)
This is actually the worst part of this story indeed.
-
Agreed.A government decree (...)
This is actually the worst part of this story indeed.
Why would any intelligent person take ANY advice that comes from the White House?!
- Wil -
Before joining the White House the guy was busy at the executive diversity and inclusion counsil at the CIA. Why not to trust the experience.
-
Before joining the White House the guy was busy at the executive diversity and inclusion counsil at the CIA.
Even better.
-
It depends what you are programming. A lot of small embedded processors are doing endless manipulation of peripherals.Though i looked at the language a while ago and honestly, if i still have to go the unsafe route to do any peripheral access might as well keep writing C...
That's a pretty silly argument even for embedded development. On all but the most trivial programs (which: who cares what you use), only a tiny fraction of the code is actually performing the register read/writes. I'm not completely thrilled with the way rust works on embedded, or the way unsafe works in rust, but most code even in embedded could be safer.
pretty much this.QuoteHowever, what you say is true for most larger embedded programs. You really ought to make life as easy as possible on the bulk of the code, so you have more time to put more focus of the gritty stuff.
and i agree very much with this as well, but that's not what i usually work on -
From perspective of somebody more familiar with device drivers than thread schedulers, memory safe languages are absolute joke when you are dealing with DMA capable hardware, limited IOMMUs (page granularity and high cost of changing page mappings) and potentially malicious external DMA peripherals (thunderbolt, USB4).
-
From perspective of somebody more familiar with device drivers than thread schedulers, memory safe languages are absolute joke when you are dealing with DMA capable hardware, limited IOMMUs (page granularity and high cost of changing page mappings) and potentially malicious external DMA peripherals (thunderbolt, USB4).
Makes sense. It's then odd that Rust has been considered first (if I got it right) for device drivers in the Linux kernel.
But even for the core part of the kernel, I think it's the wrong answer to the wrong question.
-
You just aren't going to make small embedded machines super safe to program, unless, perhaps, AI assistants get so good they pick up the errors. We need to take the wins where they present themselves. There are many weird and wonderful multi-core devices for communications applications, with very heterogeneous layouts of memory and peripherals. Good luck trying to build moderately safe programming environments for those They are a big security issue, as its often very hard to figure out from their documentation just what it is you are supposed to do in all cases.
It depends what you are programming. A lot of small embedded processors are doing endless manipulation of peripherals. However, what you say is true for most larger embedded programs. You really ought to make life as easy as possible on the bulk of the code, so you have more time to put more focus of the gritty stuff.Though i looked at the language a while ago and honestly, if i still have to go the unsafe route to do any peripheral access might as well keep writing C...
That's a pretty silly argument even for embedded development. On all but the most trivial programs (which: who cares what you use), only a tiny fraction of the code is actually performing the register read/writes. I'm not completely thrilled with the way rust works on embedded, or the way unsafe works in rust, but most code even in embedded could be safer.
I prefer to get the computer to prevent me from making as many avoidable errors as possible. Attitudes like "I can safely handle loaded guns pointed at my foot" is macho libertarian nonsense.
Twiddling bits in a register is not a major issue. Ensuring the correct bits are twiddled at the correct time is far more complex and error prone.The
Thus I don't care if peek and poke are implemented in C or assembler. Correctly calculating the invocations of peek and poke in a multimode processor is far more challenging. Any tool that helps automatically predicting those values aren't incorrect is valuable.
Just so. That's why automated support from tools is necessary.
To make that tractable you need to constrain the problem, and that is best done by having a constrained language and environment. The trick is to have constraints which are easy enough to work with and still offer useful guarantees for a large number of problems.
Hence you can't have automated accurate GC management in C/C++ because of the pointer/integer "confusion" and aliasing. Having strongly typed data enables some very interesting and effective automated GC optimisations in HotSpot; those that only know C/C++ and "learned about" GC at university don't understand how effective they can be, even/especially in common multicore NUMA architectures.
Rust appears to achieve the balance. Naturally it isn't suitable for everything, any more than C/C++ is suitable for everything. Choose the best tool for the specific job. -
From perspective of somebody more familiar with device drivers than thread schedulers, memory safe languages are absolute joke when you are dealing with DMA capable hardware, limited IOMMUs (page granularity and high cost of changing page mappings) and potentially malicious external DMA peripherals (thunderbolt, USB4).
In what way? A buffer overflow in your code to handle DMA can be chained all the way to full system control. To me it seems even more important.
Apple made a memory safe C dialect for the iOS bootloader. -
Another thing to watch out for is significantly different technologies that aren't sufficiently practical outside a laboratory/academia. Examples have been formal methods, Erlang, the various ML/Haskell/etc languages. Interesting, but not worth spending too much time on.
I'd make an exception for Erlang. I'm not so fond of the language itself, but it cannot be considered an academic language with no practical use.
Its real word applications are, in fact, all around you. A number of large companies use it (e.g. Klarna in Sweden) - Facebook chat backend used to be implemented in Erlang, but they migrated away.
But, above all, it's deployed in literally millions of radio devices in the Radio Access Network for mobile communications.
What I've personally seen in development (Note: I do not work directly with it, but I'm a user of a number services implemented with it) is a quicker turnaround time from requirement to implementation, with a quality no worse than more classical languages. -
Another thing to watch out for is significantly different technologies that aren't sufficiently practical outside a laboratory/academia. Examples have been formal methods, Erlang, the various ML/Haskell/etc languages. Interesting, but not worth spending too much time on.
I'd make an exception for Erlang. I'm not so fond of the language itself, but it cannot be considered an academic language with no practical use.
Its real word applications are, in fact, all around you. A number of large companies use it (e.g. Klarna in Sweden) - Facebook chat backend used to be implemented in Erlang, but they migrated away.
But, above all, it's deployed in literally millions of radio devices in the Radio Access Network for mobile communications.
What I've personally seen in development (Note: I do not work directly with it, but I'm a user of a number services implemented with it) is a quicker turnaround time from requirement to implementation, with a quality no worse than more classical languages.
Understood and accepted.
I have employed some of the Actor-related design patterns on high availability telecom systems written in Java. I've never been convinced that Erlang's pattern matching is "right", but that is definitely based on lack of practical understanding of how it can be used in practical systems
I heard rumours part of the IMDB website also used/uses Erlang. -
Because of this WH announcement (which I read yesterday), one of the footnotes led me to the Google Project Zero (which I have been aware of for awhile), and that led me to blog post about the NSO zero-click iMessage exploit https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html. I was only vaguely aware of Pegasus and NSO (this was in the news a year or so back), but the actual exploit, and the mind set that it took to write it, is heart stopping.
This is likely a prime candidate for why software (in general) and those parts which are widely used (in particular) needs to have a much cleaner attack footprint. Who knew that an image parser could be manipulated in this way ? -
Because of this WH announcement (which I read yesterday), one of the footnotes led me to the Google Project Zero (which I have been aware of for awhile), and that led me to blog post about the NSO zero-click iMessage exploit https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html. I was only vaguely aware of Pegasus and NSO (this was in the news a year or so back), but the actual exploit, and the mind set that it took to write it, is heart stopping.
This is likely a prime candidate for why software (in general) and those parts which are widely used (in particular) needs to have a much cleaner attack footprint. Who knew that an image parser could be manipulated in this way ?
It is also an illustration that, while your company/team may have perfectly adept C programmers, what about that library from another company and how it interacts with something else that your perfect programmers didn't develop. -
Though i looked at the language a while ago and honestly, if i still have to go the unsafe route to do any peripheral access might as well keep writing C...
Although you can access hardware directly using unsafe code, you typically wouldn't. The recommended method is to use a HAL (Hardware Abstraction Layer) library for your platform. This adds a lot of extra checks besides memory safety. For example if you attempt to use the wrong pin for an unsupported function, such as SPI on a pin that can not do SPI, your program simply won't compile. Which means your editor will make you aware that the code is invalid as you write it. You are also not allowed to read from a pin that first needs to be changed to read mode, or to make a mistake reusing the same pin for multiple purposes, etc.
Rust also provides easy concurrency (the so called "Fearless Concurrency" pattern). This is a typically problem, with many security exploits and by using this, you are eliminating another class of bugs. MCUs have multiple cores these days and you also have interrupts, DMA, etc. Your simple code to handle these things might not be as good as you think, because this is a really hard problem to solve correctly.
The simple act of manipulating some GPIO is the least of the advantages of Rust on a MCU. As described above you will get some benefits, but it is unlikely to be your GPIO code that has the security bugs. We find those in the same places as all other software: mistakes of memory allocation, deallocation, uninitialized pointers, reuse of memory containing old data, race conditions, boundary checks and so on. Why would you not have safety against all of that, just because you might need to use the unsafe keyword in some very specific parts of your code with the least changes of bugs?
-
The recommended method is to use a HAL (Hardware Abstraction Layer) library for your platform. This adds a lot of extra checks besides memory safety. For example if you attempt to use the wrong pin for an unsupported function, such as SPI on a pin that can not do SPI, your program simply won't compile.
While a good design goal for a abstraction layer, I have never seen any of this in real life. Maybe it's in some high-quality projects, but manufacturer solutions for example are much crappier: consider STM32 vendor libraries for example and you would be initializing pin modes using alternative function enumerations with no way of checking whether SPI is available on that pin or not. No such checks are made either compile time or run-time, so you totally can enable the SPI peripheral and configure a wrong pin to a wrong alternative function. No memory safety is added either, it's actually the opposite: while the direct register write has little surface area for the common memory handling errors, STM32 HAL (and many others!) use pointers for both internal state and configuration structs supplied to functions, and such pointers can accidentally point to any type of data at any address. Sure, you need colossally stupid and careless mistakes to mess something that simple up, but claiming there is some added memory safety obviously isn't true.
So usually for your nice claims to hold true you would need to develop your compile-time-checking, memory-safe hardware abstraction layer yourself. Which is then again open for any mistakes within the layer, plus added mistakes in extra housekeeping chores and interfaces. For a large team where many players contribute to the firmware it totally makes sense: put the guy who is most experienced and careful develop the most "unsafe" parts and design simple interfaces to them as to minimize risk of misuse. Per-project hardware abstractions also have the advantage that they don't need to try to support everything and therefore might be able to replace complex configuration structs and state management by lot simpler function calls.
With a smaller project completely handled by one engineer, probably a solution which accesses UART->DR directly everywhere around the code is, albeit less elegant, and slower to port, probably more memory-safe than the one which abstract it behind C functions where state and control actions are passed through pointers.
But this is of course matter of implementation. The idea is valid, and it certainly can be implemented correctly. Using a so-called "memory-safe" language if not forces but nudges you in the right direction. I'm just saying that be careful because real-world implementations have pretty poor track record when it comes to hardware abstraction on microcontrollers. -
While a good design goal for a abstraction layer, I have never seen any of this in real life.
In the case of Rust and common MCUs like STM32 the open source people already solved this. We have good crates with HALs with all the bells and whistles.
https://docs.rs/stm32-hal2/latest/stm32_hal2/
You can even generate your own from a SVD file:
https://docs.rs/svd2rust/latest/svd2rust/
-
Maybe time to think about starting alternatives.
if Linux were to implode ...- FreeBSD, NetBSD, OpenBSD <--- I've used it occasionally, but my developer chair has yet to start
- Haiku <--- not on a daily basis, but there is already a corner of my desktop dedicated to experimental with this
-
https://docs.rs/stm32-hal2/latest/stm32_hal2/
Looked at it and it still seems to miss the mentioned feature, compile-time checking of peripheral availability on given pin:Code: [Select]let mut scl = Pin::new(Port::B, 6, PinMode::Alt(4));
scl.output_type(OutputType::OpenDrain);
Still seems to map based on magic numbers. I mean, if I change that to Alt(5), or to Port::B,10, where does the compilation fail? -
https://docs.rs/stm32-hal2/latest/stm32_hal2/
Looked at it and it still seems to miss the mentioned feature, compile-time checking of peripheral availability on given pin:Code: [Select]let mut scl = Pin::new(Port::B, 6, PinMode::Alt(4));
scl.output_type(OutputType::OpenDrain);
Still seems to map based on magic numbers. I mean, if I change that to Alt(5), or to Port::B,10, where does the compilation fail?
I haven't actually any experience with the STM32 HAL. I have used the RP2040 HAL which have these features. The RP2040 HAL does not use integers for pins but types, for example pins.gpio18. Each of those have different types, so you couldn't ask gpio18 to become a function which it is not implementing.
It is still early days for embedded Rust and not all the promises have been meet yet. -
Just use Ada then instead of a cryptic language sponsored by woke hipsters with no formal specification yet.
-
To make that tractable you need to constrain the problem, and that is best done by having a constrained language and environment. The trick is to have constraints which are easy enough to work with and still offer useful guarantees for a large number of problems.
Which is why it makes much sense to have a thin C/ C++ layer and use sand-boxed languages like Lua or Python to implement the logic. A program can still crash, but the C / C++ layer can do a graceful recovery. -
Just use Ada then instead of a cryptic language sponsored by woke hipsters with no formal specification yet.
The two problems with Ada are- all the OpenSource support just sucks
there's no point even mentioning GNAT (even the pay-version) and all the crap gcc has to swallow to support the +=ada language(2)
llvm side... well, a little better, but not much - Compared to GreenHills Ada, Gnat is a toy which completely lacks tools; so it's fine for "hAllo.ads", but you won't go that far, at least without having to spend 10 times your time and effort for serious projects
So, Rust is better here, at least from an OpenSource perspective, and it has a clean(1) backend support for Clang/llvm.
(1) well "clean" ...
say it's "clean" for the mainstream architectures { x86 {32, 64}, Arm{32, 64} }
very poor for { HPPA2, MIPS{*}, PowerPC{*}, POWER, SH{*}, ... }
except Risc-V for which it has experimental but decent support.
- all the OpenSource support just sucks
-
A program can still crash, but the C / C++ layer can do a graceful recovery.
For embedded control systems, this "graceful recovery" could be logically as complex as the application itself. Possibly crash+recovery, which could takes seconds, is not acceptable in the first place.
A practical simple example would be inertial navigation system which does dead reckoning. Hardware access to the gyroscopes, accelerometers etc. is quite tightly coupled with calculation, and on the other hand, it's completely unacceptable to just die for even some milliseconds, thus simple and monolithic solutions (written and tested to strict quality standards) are preferred instead of complicated layering and allowance of high-level bugs on sandboxed area; there is not much use for the sandbox in such system. Many embedded microcontroller things are like this, not even having a GUI, or then the GUI is physically separate on a different device altogether.