This week Jonathan chats with Florian Gilcher about Rust and Ferrous Systems! How have we gotten here, what’s coming next, and what’s new in the Rust world? Watch to find out!
Continue reading “FLOSS Weekly Episode 871: Rust Won’t Save You”
rust60 Articles
Why Not Yserver? It’s Xserver, But Rust-y.
If you’re not into Wayland as a display manager, it seems like your options are slowly dwindling. Xorg isn’t exactly a hotbed of activity, and the one fork everyone knows about is best known as a political lightning rod. Luckily, Rust developers can apparently never see a tool without pulling it into their heavily oxidized bucket of crabs, so we now have another option: the creatively named yserver, released under the MIT license by [joske].
The name, yserver, for the record, is just a placeholder name, but we rather like the simple logic of “Y comes after X” — sure, you could call it X12, but that could imply continuity, and this is a clean break. It’s also not a full reimplementation of the huge, sprawling mess that Xorg has become over the decades. It can’t launch multiple screens and thus lacks full multi-monitor support. So, for now, it may be too bare-bones for some people’s use cases.
As it uses Vulkan, it is limited to relatively modern hardware, but has been tested on Intel, AMD, Nvidia, and Apple chips. The target kernel is good old Linux, but the docs do cover compiling for FreeBSD; just be aware that that’s very much a secondary target. FreeBSD users are probably used to that, though.
On Linux, a standalone DRM/KMS yserver can successfully run not just window managers but full desktops — specifically MATE, Cinnamon, and XFCE, as they’re not on the Wayland bandwagon. It even supports Compiz, in case you missed the cube and wiggly window animations. You can also use yserver via Xwayland or even Xorg. Speaking of Xorg, [joske] has run the X.Org X Test Suite (xts5) against this proposed successor, and it currently scores 66.2%, which seems pretty good considering the project explicitly does not plan to copy all of Xorg’s functionality.
Aside from multiple screens, one thing that would have been neat to see is support for the Asterinas rust-based Linux-compatible kernel — though if that project achieves full Linux compatibility, that may be a non-issue. Even if you aren’t an oxidization enthusiast, you might find reasons to be happy to see more competition in the display-manager market — after all, Wayland Will Never Be Ready For Every X11 User. If Xorg really is destined to the slow death critics predict, perhaps yserver could cover the holdouts.
Rust-y Firmware For Waveshare Smartwatch
Waveshare makes a nifty little ESP32-S3 based smartwatch product, but its firmware is apparently not to everyone’s liking. Specifically, it’s not to [infiniton] a.k.a [Bright_Warning_8406]’s liking, as they rewrote the entire code base in Rust. No_std Rust, to be specific, but perhaps that doesn’t need to be specified when dealing with ESP32.
On the Reddit thread about the project, he lists some of the advantages. For one thing, the size of the binary has dropped from 1.2 MB to 579 kB while maintaining the same functionality. More interesting is that he’s been able to eliminate polling entirely: the firmware is purely event-driven. The CPU is not just idle but parked until a timer or GPIO event wakes it up. For this form factor, that’s a big deal — you can’t fit a very large battery in a watch, after all.
Getting drivers for the AMOLED display, touch sensor, audio, and RTC modules written from scratch is an impressive accomplishment. Apparently the screen driver in particular was “a nightmare” and we believe it. There’s a reason most people go for existing libraries for this stuff. [Bright_Warning] did not post screenshots or video, but claims his version of the watch watch can make HTTP calls to Smart Home, play MP3s, play the old phone games– Snake, 2048, Tetris, Flappy Bird, Maze– and even comes with a T9 keyboard for text input.
If you’re looking to get closer to bare metal, and don’t mind it being Rust-y, take a look at the code on GitHub in the first link above. This author isn’t enough of a rustacean to say if the code is as good as it sounds at a glance, but nothing egregious jumps out. The documentation describing exactly what’s going on under the hood isn’t half-bad, either. If you aren’t into Waveshare products, you could easily adapt this code into a more DIY ESP32 watch, too.
If you’re not into Rust, uh… washing soda and electric current can get it off of steel, and probably microcontrollers too. We can’t say that the chip will work after that, but hey — no rust.
HORUS Framework: A Rust Robotics Library
[neos-builder] wrote in to let us know about their innovation: the HORUS Framework — Hybrid Optimized Robotics Unified System — a production-grade robotics framework built in Rust for real-time performance and memory safety.
This is a batteries included system which aims to have everything you might need available out of the box. [neos-builder] said their vision is to create a robotics framework that is “thick” as a whole (we can’t avoid this as the tools, drivers, etc. make it impossible to be slim and fit everyone’s needs), but modular by choice.
[neos-builder] goes on to say that HORUS aims to provide developers an interface where they can focus on writing algorithms and logic, not on setting up their environments and solving configuration issues and resolving DLL hell. With HORUS instead of writing one monolithic program, you build independent nodes, connected by topics, which are run by a scheduler. If you’d like to know more the documentation is extensive.
The list of features is far too long for us to repeat here, but one cool feature in addition to the real-time performance and modular design that jumped out at us was this system’s ability to process six million messages per second, sustained. That’s a lot of messages! Another neat feature is the system’s ability to “freeze” the environment, thereby assuring everyone on the team is using the same version of included components, no more “but it works on my machine!” And we should probably let you know that Python integration is a feature, connected by shared-memory inter-process communication (IPC).
If you’re interested in robotics and/or real-time systems you should definitely be aware of HORUS. Thanks to [neos-builder] for writing in about it. If you’re interested in real-time systems you might like to read Real-Time BART In A Box Smaller Than Your Coffee Mug and Real-Time Beamforming With Software-Defined Radio.
This Week In Security: Cloudflare Wasn’t DNS, BADAUDIO, And Not A Vuln
You may have noticed that large pieces of the Internet were down on Tuesday. It was a problem at Cloudflare, and for once, it wasn’t DNS. This time it was database management, combined with a safety limit that failed unsafe when exceeded.
Cloudflare’s blog post on the matter has the gritty details. It started with an update to how Cloudflare’s ClickHouse distributed database was responding to queries. A query of system columns was previously only returning data from the default database. As a part of related work, that system was changed so that this query now returned all the databases the given user had access to. In retrospect it seems obvious that this could cause problems, but it wasn’t predicted to cause problems. The result was that a database query to look up bot-management features returned the same features multiple times.
That featurelist is used to feed the Cloudflare bot classification system. That system uses some AI smarts, and runs in the core proxy system. There are actually two versions of the core proxy, and they behaved a bit differently when the featurelist exceeded the 200 item limit. When the older version failed, it classified all traffic as a bot. The real trouble was the newer Rust code. That version of the core proxy threw an error in response, leading to 5XX HTTP errors, and the Internet-wide fallout. Continue reading “This Week In Security: Cloudflare Wasn’t DNS, BADAUDIO, And Not A Vuln”
This Week In Security: Landfall, Imunify AV, And Sudo Rust
Let’s talk about LANDFALL. That was an Android spyware campaign specifically targeted at Samsung devices. The discovery story is interesting, and possibly an important clue to understanding this particular bit of commercial malware. Earlier this year Apple’s iOS was patched for a flaw in the handling of DNG (Digital NeGative) images, and WhatsApp issued an advisory with a second iOS vulnerability, that together may have been used in attacks in the wild.
Researchers at Unit 42 went looking for real-world examples of this iOS threat campaign, and instead found DNG images that exploited a similar-yet-distinct vulnerability in a Samsung image handling library. These images had a zip file appended to the end of these malicious DNG files. The attack seems to be launched via WhatsApp messaging, just like the iOS attack. That .zip contains a pair of .so shared object files, that are loaded to manipulate the system’s SELinux protections and install the long term spyware payload.
The earliest known sample of this spyware dates to July of 2024, and Samsung patched the DNG handling vulnerability in April 2025. Apple patched the similar DNG problem in August of 2025. The timing and similarities do suggest that these two spyware campaigns may have been related. Unit 42 has a brief accounting of the known threat actors that could have been behind LANDFALL, and concludes that there just isn’t enough solid evidence to make a determination.
Not as Bad as it Looks
Watchtowr is back with a couple more of their unique vulnerability write-ups. The first is a real tease, as they found a way to leak a healthy chunk of memory from Citrix NetScaler machines. The catch is that the memory leak is a part of an error message, complaining that user authentication is disabled. This configuration is already not appropriate for deployment, and the memory leak wasn’t assigned a CVE.
There was a second issue in the NetScaler system, an open redirect in the login system. This is where an attacker can craft a malicious link that points to a trusted NetScaler machine, and if a user follows the link, the NetScaler will redirect the user to a location specified in the malicious link. It’s not a high severity vulnerability, but still got a CVE and a fix. Continue reading “This Week In Security: Landfall, Imunify AV, And Sudo Rust”
Rust Drives A Linux USB Device
In theory, writing a Linux device driver shouldn’t be that hard, but it is harder than it looks. However, using libusb, you can easily deal with USB devices from user space, which, for many purposes, is fine. [Crescentrose] didn’t know anything about writing user-space USB drivers until they wrote one and documented it for us. Oh, the code is in Rust, for which there aren’t as many examples.
The device in question was a USB hub with some extra lights and gadgets. So the real issue, it seems to us, wasn’t the code, but figuring out the protocol and the USB stack. The post covers that, too, explaining configurations, interfaces, and endpoints.
There are other ancillary topics, too, like setting up udev. This lets you load things when a USB device (or something else) plugs in.
