rust

57 Articles

Detail of Horus's face, from a statue of Horus and Set placing the crown of Upper Egypt on the head of Ramesses III. Twentieth Dynasty, early 12th century BC.

HORUS Framework: A Rust Robotics Library

January 9, 2026 by 7 Comments

[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

November 21, 2025 by 8 Comments

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

November 14, 2025 by 7 Comments

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

June 26, 2025 by 13 Comments

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.

Continue reading “Rust Drives A Linux USB Device” →

If Your Kernel Development Is A Little Rusty

June 21, 2025 by 40 Comments

To paraphrase an old joke: How do you know if someone is a Rust developer? Don’t worry, they’ll tell you. There is a move to put Rust everywhere, even in the Linux kernel. Not going fast enough for you? Then check out Asterinas — an effort to create a Linux-compatible kernel totally in Rust.

The goal is to improve memory safety and, to that end, the project describes what they call a “framekernel.” Historically kernels have been either monolithic, all in one piece, or employ a microkernel architecture where only bits and pieces load.

A framekernel is similar to a microkernel, but some services are not allowed to use “unsafe” Rust. This minimizes the amount of code that — in theory — could crash memory safety. If you want to know more, there is impressive documentation. You can find the code on GitHub.

Will it work? It is certainly possible. Is it worth it? Time will tell. Our experience is that no matter how many safeguards you put on code, there’s no cure-all that prevents bad programming. Of course, to take the contrary argument, seat belts don’t stop all traffic fatalities, but you could just choose not to have accidents. So we do have seat belts. If Rust can prevent some mistakes or malicious intent, maybe it’s worth it even if it isn’t perfect.

Want to understand Rust? Got ten minutes?

The rust language logo being branded onto a microcontroller housing

Esp-hal, A Stable-API ESP32 HAL Gift For Your Rust Code

February 27, 2025 by 14 Comments

Looking to write Rust on the ESP32? You’re in luck, a new challenger has entered the scene, looking to help you write code that lasts – [Scott Mabin] and the team from Espressif have brought us the esp-hal 1.0.0-beta. From a personal project to an Espressif-sponsored one to an effort under Espressif’s wing, [Scott] tells us about the arduous journey of bringing first-class Rust support to ESP32 chips, Xtensa and RISC-V alike.

In particular, esp-hal, with the hal part standing for Hardware Abstraction Layer, focuses on providing you with a stable API to access hardware, making sure your code can remain stable for years to come. For now, you get drivers for GPIO, UART, SPI and I2C, as well as a number of auxiliary features like time and SoC reset, more than enough for a large amount of projects we hackers build with a generic MCU in mind.

Next stop? WiFi and BLE support, of course, an ESP32 just doesn’t feel the same without these two. Rust is a fun and seriously promising language, and it’s a joy to use! So, if you have a wireless-less project in mind and you’re looking for a HAL, try out the esp-hal, it might just be exactly what you need.

If you’re looking for examples, here’s an STM32 touchpad project with Rust firmware, a PIC32 Rust blinky demo, and we’ve even featured larger projects like this ESP32 open-source (reverse-engineered) WiFi MAC stack being written in Rust. In case you missed it, we’ve introduced Rust to you a couple of times, even as far as 2015!

UScope: A New Linux Debugger And Not A GDB Shell, Apparently

February 7, 2025 by 8 Comments

[Jim Colabro] is a little underwhelmed with the experience of low-level debugging of Linux applications using traditional debuggers such as GDB and LLDB. These programs have been around for a long time, developing alongside Linux and other UNIX-like OSs, and are still solidly in the CLI domain.  Fed up with the lack of data structure support and these tools’ staleness and user experience, [Jim] has created UScope, a new debugger written from scratch with no code from the existing projects.

GBD, in particular, has quite a steep learning curve once you dig into its more advanced features. Many people side-step this learning curve by running GDB within Visual Studio or some other modern IDE, but it is still the same old debugger core at the end of the day. [Jim] gripes that existing debuggers don’t support modern data structures commonly used and have poor customizability. It would be nice, for example, to write a little code, and have the debugger render a data structure graphically to aid visualisation of a problem being investigated. We know that GDB at least can be customised with Python to create application-specific pretty printers, but perhaps [Jim] has bigger plans?

Continue reading “UScope: A New Linux Debugger And Not A GDB Shell, Apparently” →