From: Jens Axboe <axboe@kernel.dk>
To: io-uring@vger.kernel.org
Subject: [PATCHSET RFC 0/2] Per-task io_uring opcode restrictions
Date: Thu, 8 Jan 2026 13:17:23 -0700 [thread overview]
Message-ID: <20260108202944.288490-1-axboe@kernel.dk> (raw)
Hi,
One common complaint is that io_uring doesn't work with seccomp. Which
is true, as seccomp is entirely designed around a classic sync syscall -
if you can filter what you need based on a syscall number and the
arguments, then it's fine. But for anything else, it doesn't really
work. This means that solutions that rely on syscall filtering, eg
docker, there's really not much you can do with seccomp outside of
entirely disabling io_uring. That's not ideal.
As I do think that's a gap we have that needs closing, here's an RFC
attempt at that. Suggestions more than welcome! I want to arrive at
something that works for the various use cases.
io_uring already has a filtering mechanism for opcodes, however it needs
to be done after a ring has been created. The ring is created in a
disabled state, and then restrictions are applied, and finally the ring
is enabled so it can get used. This is cumbersome and doesn't
necessarily fit everybody's needs.
This patch adds support for extending that same list of disallowed
opcodes and register to something that can be applied to the task as a
whole. Once applied, any ring created under that task will have these
restrictions applied. Patch 1 adds the basic support for this, and patch
2 adds support for having the restrictions applied at fork or thread
create time too, so any task or thread created under the current task
will get the same restrictions.
A few test cases can be found in liburing, in the task-restrictions
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/liburing.git/log/?h=task-restrictions
include/linux/io_uring.h | 2 +-
include/linux/io_uring_types.h | 2 ++
include/linux/sched.h | 1 +
include/uapi/linux/io_uring.h | 16 ++++++++++++++
io_uring/io_uring.c | 10 +++++++++
io_uring/register.c | 39 ++++++++++++++++++++++++++++++++++
io_uring/tctx.c | 23 ++++++++++++--------
kernel/fork.c | 6 ++++++
8 files changed, 89 insertions(+), 10 deletions(-)
--
Jens Axboe
next reply other threads:[~2026-01-08 20:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 20:17 Jens Axboe [this message]
2026-01-08 20:17 ` [PATCH 1/2] io_uring: allow registration of per-task restrictions Jens Axboe
2026-01-08 20:17 ` [PATCH 2/2] io_uring/register: add support for inheriting task restrictions Jens Axboe
2026-01-08 22:04 ` [PATCHSET RFC 0/2] Per-task io_uring opcode restrictions Gabriel Krisman Bertazi
2026-01-08 23:54 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260108202944.288490-1-axboe@kernel.dk \
--to=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox