linux: add experimental io_uring restrictions by gvozdetsky · Pull Request #2386 · containers/crun

gvozdetsky · 2026-10-19T13:16:24Z

seccomp can't filter io_uring operations: they are submitted through the ring, not as syscalls, so runtimes currently block io_uring entirely. Linux 7.0 added task-level io_uring BPF filters, which are inherited across fork and exec and can only be tightened, like seccomp.

This adds experimental support behind the run.oci.io_uring annotation, in the shape proposed for linux.ioUring in opencontainers/runtime-spec#1328 (proposal: opencontainers/runtime-spec#1323):

{
  "ops": ["IORING_OP_READ", "IORING_OP_WRITE", "IORING_OP_SOCKET"],
  "socketFamilies": ["AF_UNIX", "AF_INET", "AF_INET6"]
}

ops is an allowlist, every other operation is denied. It doesn't depend on the SQE flags.
socketFamilies, when present, limits IORING_OP_SOCKET to these families. It requires IORING_OP_SOCKET in ops, and an empty list is refused; to deny all sockets, leave IORING_OP_SOCKET out of ops.
The policy is validated, and kernel support checked, before the container is created or restored, and before crun exec.
It is applied to the container init and to every crun exec process (they don't inherit it from init). Like seccomp, registering a filter needs no_new_privs or CAP_SYS_ADMIN, so it is applied before the capabilities are dropped, or, with noNewPrivileges, once no_new_privs is set; in both cases before seccomp.
CRIU doesn't restore the restrictions, so on crun restore crun applies them to itself before running CRIU, and the restored processes inherit them.
Only BPF filters are used, never IORING_REGISTER_RESTRICTIONS, so the workload can still add its own filters.

youki has the same semantics in youki-dev/youki#3805, so the spec shape is now implemented by two runtimes. Once the spec has the field, the annotation will be replaced by linux.ioUring.

Tests: tests/test_io_uring.py checks the policy in init and in exec (with and without noNewPrivileges), SQE-flag independence, deny-all, and invalid policies; checkpoint-restore-io-uring checks the init of a restored container. They are skipped on kernels without io_uring BPF filters. On Linux 7.0 they pass, and each of them fails with the corresponding apply call removed. The exec, seccomp, capabilities and checkpoint/restore tests pass too.

giuseppe

left some comments, we also need the check and libcrun_apply_io_uring_restrictions for the libcrun_container_restore case

giuseppe · 2026-10-20T09:49:20Z

+};
+
+/* The io_uring opcodes, in `enum io_uring_op` order.  */
+static const char *io_uring_ops[] = {


this looks painful to maintain, but I can't see any alternative given what the uapi offers

Agreed. enum io_uring_op has no macros, so there is no way to get the names, or even to check the table against the headers. New opcodes are appended, so it is one line per release, and an opcode the running kernel doesn't know is skipped (EINVAL), so the table may be ahead of the kernel.

giuseppe · 2026-10-20T10:10:50Z

+                                 IO_URING_ANNOTATION);
+          goto exit;
+        }
+


Opus 5.5 suggests to not accept socketFamilies without IORING_OP_SOCKET_VALUE:

+ if (UNLIKELY (! policy->ops[IORING_OP_SOCKET_VALUE])) + { + ret = crun_make_error (err, 0, "%s: `socketFamilies` requires IORING_OP_SOCKET in `ops`", IO_URING_ANNOTATION); + goto exit; + } +

Done, a policy with socketFamilies but without IORING_OP_SOCKET in ops is now refused. I changed the spec proposal (opencontainers/runtime-spec#1328) and youki (youki-dev/youki#3805) the same way, so they stay in sync.

giuseppe · 2026-10-20T10:26:14Z

+  /* Before seccomp, which may deny io_uring_register, and before the
+     capabilities are dropped: like seccomp, the restrictions need
+     CAP_SYS_ADMIN or no_new_privs.  */


Suggested change

/* Before seccomp, which may deny io_uring_register, and before the

capabilities are dropped: like seccomp, the restrictions need

CAP_SYS_ADMIN or no_new_privs. */

/* Before seccomp, which may deny io_uring_register, and before the

capabilities are dropped: registering a filter needs CAP_SYS_ADMIN

in the user namespace. */

no_new_privs is set later as part of libcrun_set_caps.

Should we do like seccomp that we try to apply it in two different places?

Good catch, no_new_privs isn't set at that point, so it only worked thanks to CAP_SYS_ADMIN. It is now done like seccomp: without noNewPrivileges before the capabilities are dropped, otherwise once libcrun_set_caps has set no_new_privs, both for the init and for exec, and in both cases before seccomp. The tests now run with both values of noNewPrivileges.

giuseppe · 2026-10-20T10:30:02Z


  if (UNLIKELY (container_paused))
    return crun_make_error (err, 0, "cannot exec in a paused container `%s`", id);



do we need to add here a check for exec'ed processes?

ret = libcrun_check_io_uring_restrictions (container, err); if (UNLIKELY (ret < 0)) return ret;

gvozdetsky · 2026-10-20T11:47:50Z

@giuseppe thanks for the review. About restore: added both. The check is done before anything is created, and crun applies the restrictions to itself before running CRIU, like the keyring: CRIU doesn't restore them, but the restored processes inherit them from CRIU. crun itself stays restricted for the rest of the restore, which is fine as it doesn't use io_uring. The new checkpoint-restore-io-uring test checks the init of the restored container, not an exec.

The fixes are fixup commits for now, I'll squash them once you are happy with them.

giuseppe

thanks, LGTM

@kolyshkin PTAL

seccomp cannot filter io_uring operations, as they are submitted through the ring and not as syscalls, so today the only option is to block io_uring entirely. Linux 7.0 added task-level io_uring BPF filters, which are inherited across fork and exec and can only be tightened, like seccomp. Add the run.oci.io_uring annotation, in the shape proposed for linux.ioUring in opencontainers/runtime-spec#1328: {"ops": [...], "socketFamilies": [...]} ops is an allowlist of IORING_OP_* names, every other operation is denied. socketFamilies, when present, limits IORING_OP_SOCKET to the listed address families. It must not be empty, and ops must contain IORING_OP_SOCKET. The policy is validated, and kernel support checked, before the container is created or restored, and before a process is exec'ed in it. Registering a filter needs either no_new_privs or CAP_SYS_ADMIN, so, like seccomp, the restrictions are applied to the container init and to every exec'ed process before the capabilities are dropped, or with noNewPrivileges once no_new_privs is set. In both cases they are applied before seccomp, which may deny io_uring_register. CRIU does not restore them, so on restore crun applies them to itself before running CRIU, and the restored processes inherit them. Only BPF filters are used, never IORING_REGISTER_RESTRICTIONS, so the SQE flags are not restricted and the workload can still add its own filters. The annotation will be replaced by linux.ioUring once it is in the runtime spec. Assisted-by: Claude Code (claude-opus-5-5) Signed-off-by: Eugene Gvozdetsky <gvozdet@gmail.com>

Add an "io_uring" command to tests/init that submits one SQE per argument on a new ring and reports whether it was denied, an "io_uring-once-restored" command that does the same once the container is restored, and a "check-feature io_uring-restrictions" probe. The tests check the policy in the container init and in an exec'ed process, with and without noNewPrivileges, and in a restored container, that whether an operation is allowed does not depend on its SQE flags, that an empty ops denies everything, and that invalid policies are refused. They are skipped on kernels without io_uring BPF filters. Assisted-by: Claude Code (claude-opus-5-5) Signed-off-by: Eugene Gvozdetsky <gvozdet@gmail.com>

giuseppe requested changes Oct 20, 2026

View reviewed changes

giuseppe approved these changes Oct 20, 2026

View reviewed changes

gvozdetsky added 2 commits October 23, 2026 15:00

gvozdetsky force-pushed the io-uring-restrictions branch from 45fde5f to 216ab3b Compare October 23, 2026 13:00

gvozdetsky mentioned this pull request Oct 23, 2026

libcontainer: experimental io_uring restrictions (Linux 7.0+) youki-dev/youki#3805

Open

Navigation Menu

Repository navigation

linux: add experimental io_uring restrictions - #2386

linux: add experimental io_uring restrictions#2386
gvozdetsky wants to merge 2 commits into
containers:mainfrom
gvozdetsky:io-uring-restrictions

gvozdetsky commented Oct 19, 2026 •

edited

Loading

Uh oh!

giuseppe left a comment

Uh oh!

giuseppe Oct 20, 2026

Uh oh!

gvozdetsky Oct 20, 2026

Uh oh!

giuseppe Oct 20, 2026

Uh oh!

gvozdetsky Oct 20, 2026

Uh oh!

giuseppe Oct 20, 2026

Uh oh!

gvozdetsky Oct 20, 2026

Uh oh!

giuseppe Oct 20, 2026

Uh oh!

gvozdetsky Oct 20, 2026

Uh oh!

gvozdetsky commented Oct 20, 2026

Uh oh!

giuseppe left a comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		if (UNLIKELY (container_paused))
		return crun_make_error (err, 0, "cannot exec in a paused container `%s`", id);

Conversation

gvozdetsky commented Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

giuseppe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gvozdetsky commented Oct 20, 2026

Uh oh!

giuseppe left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gvozdetsky commented Oct 19, 2026 •

edited

Loading