Redox OS Development Priorities for 2025/26
Posted3 months agoActive3 months ago
redox-os.orgTechstory
calmpositive
Debate
40/100
Redox OSOperating System DevelopmentSecurity
Key topics
Redox OS
Operating System Development
Security
The Redox OS team has outlined their development priorities for 2025/26, sparking discussion on the project's direction, security features, and technical decisions.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
2h
Peak period
13
6-12h
Avg / period
5
Comment distribution25 data points
Loading chart...
Based on 25 loaded comments
Key moments
- 01Story posted
Sep 25, 2025 at 2:29 PM EDT
3 months ago
Step 01 - 02First comment
Sep 25, 2025 at 4:48 PM EDT
2h after posting
Step 02 - 03Peak activity
13 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 28, 2025 at 4:32 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45376895Type: storyLast synced: 11/20/2025, 12:32:34 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I get the various little services might change, but ultimately the kernel supporting posix like threading and memory operations should be mostly enough?
Also, I’m curious about the mention of drivers being in user space. Why would one want their drivers in user space? Wouldn’t that increase the attack surface?
Security benefits of driver's being in user space become limited quickly if you lack an iommu. Additionally if it has to set things like voltage regulators or clocks it can easily put the system into precarious states. That said it's still worthwhile and has lots of other benefits.
> In order to avoid porting thousands of device drivers, we would like to port QEMU to Redox, then run a stripped-down Linux to provide device drivers for less common and older devices. The interface between Redox and Linux-in-QEMU will be designed to be secure, so this approach should give us reasonable safety.
What a fascinating approach to this.
Is it something like:
USB directly to the guest OS, then an emulated serial port in the guest OS back that the host OS connects to?
Some related work in the SR-IOV & iommu space makes this a lot easier to implement as well. I would be very surprised if zero new security edge cases get discovered in the next five years or so however. Regardless, I'd look forward to seeing the results of RedoxOS's work here, as this would be a practical alternate implementation of driver domains like you see used in Xen and Qubes.
Regarding the server approach, I wonder if going for a type 1 hypervisor like Firecracker wouldn't be a much better approach than QEMU.