r/rust • u/awesomePop7291 • 1d ago
🎙️ discussion Rust in the kernel? What about Rust without the kernel!
https://kerkour.com/rust-kernelBare-metal Rust may have a brighter future than micro-kernels.
29
u/IOnlyEatFermions 1d ago
WiFi router is a terrible example. It needs chipset drivers, an IP stack, and management protocols. Nobody is writing those from scratch and the ones that are available (open source or not) are developed to operate within or on top of an OS, or are barely tested and likely full of bugs.
1
u/throwaway490215 11m ago
Nobody is writing those from scratch
An AI will. You just need the right reference docs and this really isn't a problem. The bugs exists in every stack, but with the reduced attack surface of using Rust + no Linux, plus you can connect many and have AI churn through testing a massive configuration-space gives something that is good enough.
Let me /rant a bit and say that - perhaps not you as the commenter - but seeing /r/rust upvote this because people here want to stay ignorant on where SoTA AI is at is a bit sad.
14
u/alietors 1d ago
I don't know, it might have their use, but currently you can have Linux distribution that are just a few MB (alpine slim is 5MB) and it solves lots of problems.
The fact that AI can solve a problem easily doesn't make more wise reinventing the wheel every time. There's no need and spending time and tokens (money and resources) in doing the same thing over and over again when it's already solved doesn't seem a good idea to me.
7
u/_Happy_Camper 1d ago
Having a slim OS there makes managing test and emulator environments for your build pipeline so much easier. It depends on the complexity of what you’re building of course but I can’t think of anything offhand where I’d prefer no OS
13
u/creeper6530 1d ago
Given a correct spec, an LLM can write you an entire embedded system in a few hours of work.
BULLSHIT. Maybe it can create one, but not one anywhere usable.
8
u/P00351 21h ago
Yeah, A very comprehensive and precise spec.
That strip is 10 years old and still relevant
3
u/creeper6530 18h ago edited 17h ago
Well that's exactly my point lol
3
u/P00351 17h ago
Yes, sorry. I just felt the comic was a better way of expressing it.
5
u/creeper6530 17h ago
No, I agree, the comic is recognisable enough to better communicate my point than my words. Do not apologise
11
2
u/mdedetrich 22h ago
I will call bullshit an your bullshit. If you have a correct and formally verified spec, along with a systematic way to test against the spec, this is heaven for LLM's and you can easily create usable systems with oversight from senior engineers.
6
u/numerical_panda 21h ago
Congratulations! You just invented a deterministic formal programming language!
0
u/mdedetrich 20h ago
You don't even need a formally verified spec. The bun rewrite (which was 500 million lines) of zig to rust using AI was successful due to the massive already existing testing corpus which gave the adversarial AI agents something to measure against when reviewing the other AI agents that did the code migration.
In any case, this is a classic example of "unintentionally showing you don't know how AI works without explicitly saying it".
2
u/numerical_panda 20h ago edited 20h ago
massive already existing testing corpus
Which I presume existed way before LLM's, i.e. a human-written formally verified spec written in a deterministic formal programming language?
-1
u/mdedetrich 20h ago edited 20h ago
Nope, when Bun was written in Zig, most code was written by agents but supervised with people (including tests).
Again a case of not knowing how AI works. I just recently vibecoded a project from scratch (due to extremely optimistic deadline) and by default, AI's like Claude will write tests along with any feature work without even needing to prompted.
In my case, around 90% of those tests was written correctly with another 5% being above what I would have done and with the rest being wrong (by some definition of wrong), hence why you need human supervision.
And by "testing by default", I mean that Claude will automatically write the test, mutate it to actually prove its not testing something vacuous and automatically run tests whenever feature/project/bug work is done.
The actual distinction is not, whether it was written beforehand by humans or not, its how novel it is.
32
u/matthieum [he/him] 1d ago
I find the timing of this post amusing, as I had yet another experience today -- after a month or so -- reminding me how bare bones is a really pain in the butt.
This experience was not about an embedded device, but about a Docker container, built atop a bare bones Alpine image.
Due to being slim by default, Alpine is used a lot as the base of Docker container. You install just what you need, and you have a pretty slim image. Awesome.
And then, just as today, something doesn't work, so you reach for your usual Linux toolbox to diagnose the problem and... well, too bad. There's no Linux toolbox in this Docker image. Oopsie.
I can already see the same happening with bare-metal applications, except worse. In a Docker container, if you're missing a tool, you can still install it. So it's a momentary inconvenience, but not the end of the world. In your bare-metal application, if you suddenly need to dig into, say, DNS resolution, routing issues, etc... well, good luck mate. I'll be sipping my cocktail on the beach ;)
5
u/syklemil 21h ago
In a Docker container, if you're missing a tool, you can still install it.
I'll raise ya distroless containers, at which point the container really is approaching a very fat static binary, with no
sh, noapk, more likely just glibc, some certificates and your app, and likely running all on an immutable FS except for some tiny scratch space in/tmp.There's definitely aspects about that that I like, but I'm not gonna pretend needing another image for debugging is anything but a PITA.
2
u/colingwalters 11h ago
And then, just as today, something doesn't work, so you reach for your usual Linux toolbox to diagnose the problem and... well, too bad. There's no Linux toolbox in this Docker image. Oopsie.
I think this is a poor example because it's really not that hard to e.g. introspect a running container from the outside, using the host system or another container image with debugging tools. Kubernetes has support for this:
https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container
I think there's a high overlap between the embedded space here and the "unikernel" concept, see https://tritoncloud.io/blog/unikernels-are-unfit-for-production which makes this argument - but the "unikernel" was more promoted for datacenter usage.
3
u/flying-sheep 1d ago
I mean, take a look at the new ESP32-S31, a dual-core RISC-V CPU running at 320MHz with Bluetooth, WiFi, USB and support for up to 32 MB of RAM.
I have this puppy right here on my desk in front of me. No idea what to do with it but it can do anything, and is super easy to work with: https://github.com/flying-sheep/esp32-s31
Just nightly Rust (since riscv32imafc-esp-espidf is a Tier 3 target), it has std support.
7
u/nonotan 1d ago
I have nothing against bare-metal. I think it's the obvious choice for many applications, really. That being said... it's rather concerning (understatement) that people are, with a straight face, telling me that it's better for security to have an LLM vomit a pool of brand-new, completely untested and unproven spaghetti code than to rely on heavily audited, regularly updated software used by billions of devices, because security updates (i.e. other people doing free security work for you) are annoying.
Yes, it is technically true that the attack surface is smaller with bare-metal. But that's like saying the attack surface is smaller on a small fishing boat than on a nuclear aircraft carrier. Technically true, but not really implying what you're implying it implies. Let's be honest here, very few bare-metal devices can survive an attack by even a mildly dedicated hobbyist that has access to the hardware. And if we're ruling out hardware access, it's fairly trivial to make a pretty airtight device on Linux or whatever. If you aren't capable of achieving that, even though the tools to get 99% of the way there all come served on a silver platter, the security on your completely novel bare-metal software is going to be a disaster.
(And to also be honest, a lot of the time security considerations on an embedded device aren't that important... namely on pretty much any device neither connected to the internet nor handling particularly sensitive data or doing anything safety-critical. But that's true regardless of approach)
1
u/Shoddy-Childhood-511 17h ago
Yes exactly, the article becomes bullshit the moment they claim bespoke unikernels could be more secure than more battle tested kernels. Yes LLMs make this worse, but even if all human code the bespoke unikernel would still be a flock of zero days flying in formation.
It's true Linux might brings risks from its complexity, although a slimmed down Linux using SE Linux sounds pretty strong. There are many micro-kernels designed for security like Xous from https://betrusted.io
https://media.ccc.de/v/39c3-xous-a-pure-rust-rethink-of-the-embedded-operating-system
3
u/CrazyDrowBard 1d ago
Embassy is great! I used it for an esp32 card and it made my life so much easier. Code was so much cleaner to me than my arduino code
8
u/Anaxamander57 1d ago
Is there any indication LLMs produce embeded code that is even useful? It seems like the kind of thing they would suck at, actually.
-1
u/occamatl 1d ago
I've had Claude build everything that I've requested into a LilyGo T-Watch-Ultra using bare-metal Rust. I was tremendously impressed.
2
u/Lalelul 1d ago
I agree with the premise of the post. Rust has been a wonderful experience to work on embedded with! I have developed a split keyboard using two NRF52840 (source code: https://github.com/Quoteme/corne-rmk) and it was great.
LLMs were not capable of working with he borrow checker and some Bluetooth communication yet though, so I had to do these parts myself, so I do not fully agree in this regard.
However, it's so much better to have algebraic data types on embedded! Specifically the result type. I don't want to work with a language where some code can just throw and error and suddenly nothing works anymore.
2
u/SeeMonkeyDoMonkey 23h ago
Unikernels were the next big thing for a while, on similar reasoning.
It turns out that it's nice to have systems to help do logging, process management, debugging.
If you're writing all your own versions of that in Rust, I guess you've just written an OS - which is fine if that's what you really want to be doing.
Oxide's Hubris OS, looks to be a great solution for their requirements.
1
1
0
u/No_Frame3855 1d ago
OP you may find Saikuro cool
(my project BTW)
1
u/No_Frame3855 1d ago
Docs are wayyyyy out of date right now, that's the thing that I'll work on next, but no_std is supported first class and memory usage is like 20-30 kb on average.
88
u/Uwulmindor 1d ago
Very much this. I'm in the embedded rust space and I also see it as an interesting possible paradigm shift.
Embedded-rust abstractions already solve most peripheral driver unification issues, the main remaining problems tend to be memory isolation (aka user mode) and interrupt handling. But the latter is also mostly solved already.