<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e" -->

---
title: Redox: Ring Buffers Project Summary | daily.dev
description: The Redox OS team finished the first phase of an NLnet-funded project adding io_uring-like ring buffer support for communication between applications and...
canonical: https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Redox: Ring Buffers Project Summary | daily.dev
og:description: The Redox OS team finished the first phase of an NLnet-funded project adding io_uring-like ring buffer support for communication between applications and...
og:url: https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e
og:image: https://api.daily.dev/og/posts/n2qxhJV8E.png
og:image:alt: Redox: Ring Buffers Project Summary
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Redox: Ring Buffers Project Summary

**[Hacker News](https://daily.dev/sources/hn)** · 11 min read · 0 upvotes · 0 comments

## Summary

The Redox OS team finished the first phase of an NLnet-funded project adding io_uring-like ring buffer support for communication between applications and system services. The new 'redox-rings' crate and 'redox-ring API' let applications submit async I/O requests directly to userspace scheme processes without kernel involvement or memory copies. A benchmark shows the ring interface is 14 to 15 times faster than synchronous syscalls. The team also optimized kernel IPC: direct context switching cut IPC latency by 15 to 20%, and huge pages reduced the highest observed L1DTLB-miss rate in heavy forking by 75%. Overall IPC roundtrip latency dropped from about 5800 to 2700 cycles.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.redox-os.org/news/nlnet-rb-summary>

## Questions this post answers

### How much faster is Redox's new ring buffer I/O interface compared to regular syscalls?

Redox's new redox_ring interface is 14 to 15 times faster than the redox_syscall benchmark, based on benchmarks comparing synchronous system call I/O against the new Redox Rings interface. The redox_ring interface allows applications to submit I/O requests directly to scheme processes asynchronously without kernel involvement or memory copies.

_Developers tracking async I/O performance work can follow OS internals benchmarks like this on daily.dev._

### What is the Redox Rings API and how is it similar to Linux io_uring?

Redox Rings is an async I/O interface for Redox OS modeled on Linux's io_uring and liburing, using submission queue (SQ) and completion queue (CQ) ring buffers shared via memory. Unlike io_uring, which submits operations to the kernel, Redox Rings lets applications submit requests directly to userspace scheme processes without memory copies, using a separate shared DMA-capable memory region.

_Anyone comparing io_uring-style async I/O designs across OSes can track these deep dives on daily.dev._

### How much did direct context switching reduce IPC latency in the Redox kernel?

Direct context switching, implemented in kernel merge request 694, reduced IPC latency by 15 to 20% on Redox OS. It separates the 'scheduled context' from the 'running context' so a client calling a scheme can bypass the scheduler entirely and switch directly to the scheme when ready, similar to how monolithic kernels handle complex syscalls.

_Engineers optimizing kernel IPC paths can keep up with microkernel performance work via daily.dev._

## Community take

How the wider developer community reacted, aggregated from 1 discussion and 15 comments across hackernews (as of 2026-10-31).

**TL;DR:** The technical depth of the ring buffer and IPC optimization work is well received, but much of the discussion veers into a side debate about whether io_uring on Linux is actually a security liability, with sources cited on both sides.

**Sentiment:** 45% positive · 20% mixed · 35% skeptical

**The case for**

- The work is seen as technically sound, well-researched, and a thoughtful, targeted approach to improving IPC performance.
- The kernel's choice to zero vector registers for correctness rather than optimizing for speed is viewed as a sign of care around security/correctness.
- Some see this as a meaningful step that could extend beyond storage to other I/O domains like wireless.

**The pushback**

- Several commenters argue io_uring has a serious security track record on Linux, citing disabled syscall filtering (seccomp) and a high proportion of kernel exploit bounty submissions targeting it.
- One commenter disputes the post's characterization that io_uring's early security issues have been fully resolved.

**By community**

- hackernews (mixed): Praise for the technical rigor of the Redox work is mixed with a substantial side debate over whether io_uring is genuinely secure on Linux.

**Hottest debate:** Whether io_uring's security issues on Linux have truly been resolved or remain a serious, ongoing problem.

**Open questions**

- How would the async executor benchmark results compare directly against Linux's io_uring performance?
- Could the ring buffer approach be extended to other I/O domains like wireless/Bluetooth?

**Highlights**

> This is great work by the Redox team. This might be over the heads of many HNers who are undergoing skill atrophy in real time and addicted to agents, given that 4 hours and less than 10 comments on a highly technical blog post about Rust and asynchronous I/O in Redox. This project is vehemently against AI usage of any kind, so I can trust that the contents of this post has been checked and written by someone who has read the code and knows what they are doing. > The Linux io_uring interface allows the user to submit one or more I/O operations to the kernel, which are then processed in an asynchronous fashion without blocking the userspace process. Redox, being a microkernel, handles I/O in userspace scheme processes rather than in the kernel. io_uring is incredibly fast for async I/O but is also a massive security disaster in the Linux kernel. As long as Redox is able to show a secure interface for async I/O the better. Likely part of their long term goals for the OS. > While it has substantially improved over the years, IPC is still quite slow on Redox, and this is important to optimize as ring buffers can only offset this overhead to a certain extent. This has been a focus of our work to improve system performance. I quite like this targeted and thoughtful approach for a wholistic improvement starting with ring buffers in redox. They need to compare the async executor benchmark results with Linux and continue from there for improvements. > The optimization made here is that the kernel zeroes the vector registers if the caller and callee entered the kernel through syscalls, rather than saving/restoring (using vzeroall, ldmxcsr etc. as required for correctness). Interesting approach for complete correctness over performance in this area and this tells me that they are not taking going to risk on overlying on rust's "guarantees" to help them prevent races or data reuse after free bugs in the Redox kernel. One of the most technically sound and researched posts I've read, but unfortunately it has been buried under low effort slop posts on HN.
> — [rvz on hackernews · 2 comments](https://news.ycombinator.com/item?id=50320279)

> The Redox article is underselling it somewhat. Part of the problem is Linux's historical syscall restriction systems (seccomp) did not (does not?) apply to io_uring, so io_uring is (was?) all or nothing on async versions of syscalls it implements.  Also, io_uring is rapidly adding API surface compared to other parts of the kernel.  With these factors combined, it has had repeated security problems since 2019 and has lead to, e.g., Android disabling io_uring entirely for applications. https://security.googleblog.com/2023/06/learnings-from-kctf-... > in the past year, there has been a clear trend: 60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone). Furthermore, io_uring vulnerabilities were used in all the submissions which bypassed our mitigations.
> — [loeg on hackernews · 1 comments](https://news.ycombinator.com/item?id=50320833)

> Could you elaborate on io_uring being a security disaster? The Redox article has the following to say: > In its early days, io_uring did have a few security issues and memory leaks, but these have since been addressed The article also links to a GitHub discussion where someone explains how io_uring is actually all right (see https://github.com/axboe/liburing/discussions/1047#discussio... ). (I don't have a horse in this race, I just like being well informed and had reconciled myself with io_uring being secure as a consequence of the Redox article.)
> — [wofo on hackernews · 1 comments](https://news.ycombinator.com/item?id=50320452)

> This is cool stuff !! Would love to see what other things could benefit from this beyond storage. Maybe like BT or similar wireless.
> — [happyPersonR on hackernews](https://news.ycombinator.com/item?id=50319544)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=50274186) · 45 points · 15 comments

## Similar posts on daily.dev

- [Redox OS Landed Nice Performance Improvements In September](https://daily.dev/posts/redox-os-landed-nice-performance-improvements-in-september-hsqp6bexw) · Phoronix · 2 upvotes · 0 comments
- [IO\_uring Zero-Copy Large Receive Buffer Support To Provide A Nice Performance Win](https://daily.dev/posts/io-uring-zero-copy-large-receive-buffer-support-to-provide-a-nice-performance-win-c7ydvpphl) · Phoronix · 0 upvotes · 0 comments
- [This Month in Redox](https://daily.dev/posts/this-month-in-redox-kxksov76v) · Lobsters · 7 upvotes · 0 comments

---

Tags: [#linux](https://daily.dev/tags/linux), [#rust](https://daily.dev/tags/rust)

[View this post on daily.dev](https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Redox: Ring Buffers Project Summary","url":"https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e"},"datePublished":"2026-10-31T19:50:06.526Z","dateModified":"2026-10-31T22:50:41.851Z","description":"The Redox OS team finished the first phase of an NLnet-funded project adding io_uring-like ring buffer support for communication between applications and...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/70180d70ea1a9048a8afc214293af22a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/70180d70ea1a9048a8afc214293af22a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,rust","timeRequired":"PT11M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Redox: Ring Buffers Project Summary"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/redox-ring-buffers-project-summary-n2qxhjv8e#faq","mainEntity":[{"@type":"Question","name":"How much faster is Redox's new ring buffer I/O interface compared to regular syscalls?","acceptedAnswer":{"@type":"Answer","text":"Redox's new redox_ring interface is 14 to 15 times faster than the redox_syscall benchmark, based on benchmarks comparing synchronous system call I/O against the new Redox Rings interface. The redox_ring interface allows applications to submit I/O requests directly to scheme processes asynchronously without kernel involvement or memory copies. Developers tracking async I/O performance work can follow OS internals benchmarks like this on daily.dev."}},{"@type":"Question","name":"What is the Redox Rings API and how is it similar to Linux io_uring?","acceptedAnswer":{"@type":"Answer","text":"Redox Rings is an async I/O interface for Redox OS modeled on Linux's io_uring and liburing, using submission queue (SQ) and completion queue (CQ) ring buffers shared via memory. Unlike io_uring, which submits operations to the kernel, Redox Rings lets applications submit requests directly to userspace scheme processes without memory copies, using a separate shared DMA-capable memory region. Anyone comparing io_uring-style async I/O designs across OSes can track these deep dives on daily.dev."}},{"@type":"Question","name":"How much did direct context switching reduce IPC latency in the Redox kernel?","acceptedAnswer":{"@type":"Answer","text":"Direct context switching, implemented in kernel merge request 694, reduced IPC latency by 15 to 20% on Redox OS. It separates the 'scheduled context' from the 'running context' so a client calling a scheme can bypass the scheduler entirely and switch directly to the scheme when ready, similar to how monolithic kernels handle complex syscalls. Engineers optimizing kernel IPC paths can keep up with microkernel performance work via daily.dev."}}]}
```

