Linux 6.6 Will Make It Easy To Disable IO_uring System-Wide

[phoronix]

Phoronix: Linux 6.6 Will Make It Easy To Disable IO_uring System-Wide

While IO_uring has been one of the most interesting kernel innovations of recent years and can allow for great speed-ups to async I/O, there have been some security concerns and with the Linux 6.6 kernel it will be easier for Linux administrators to disable it system-wide if so desired...

https://www.phoronix.com/news/Linux-6.6-sysctl-IO_uring

[kpedersen]

Linux 6.6 Will Make It Easy To Disable IO_uring System-Wide

BSD also makes it very easy to keep IO_uring disabled system-wide too

In some ways it is annoying that a great use-case for this tech is for large multi-user servers but at the same time, some guys might only consider enabling it for offline devices.
I tried it out for atomic modesetting for libdrm (i.e in place of this) for one offline project but in my measurements, I couldn't really make best use of it.

[zexelon]

Well this will be really handy! I am having some really bad pain points with io_uring and glusterfs these days... its bugs somewhere... but no time to track it down... It will be handy to have a toggle to just disable it!

[bachchain]

IO_uring has yielded some security concerns and vulnerabilities particularly for those sticking to older versions of the Linux kernel.

And this will help that...how exactly?

[doublez13]

I'm curious why they haven't put an LSM hook in front of IO_uring.
It feels like the perfect use case.

But clearly I'm not a kernel dev

[MorrisS.]

Is a long term solution addressed to fix these vulnerabilities without disabling IO_uring?

[doublez13]

And this will help that...how exactly?

When It's 2026 and you're still running your old 2023 kernel, at least you'll be able to disable IO_uring easily lol

[vitalif]

very sad to hear that the first really good async I/O interface gains the reputation of being insecure
I use it in my project https://vitastor.io - it's really convenient and improves performance a lot
I'd even say that I'd prefer all synchonous syscalls replaced with io_uring variants synchronous APIs are bad
for example, the same QEMU driver (my driver) gives 50k iops without io_uring and 90k iops with io_uring. just because of lower syscall count

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring

25 vulnerabilities, 13 of them are caused by "fixed buffer", "fixed file" manipulations and poll registration. these are things which I don't use

[microcode]

Is a long term solution addressed to fix these vulnerabilities without disabling IO_uring?

The work has been ongoing for over a year, it just takes time to work out issues with a new interface like this. There's nothing inherently unsecure about io_uring, it's just uncovering a lot of footguns in the kernel interfaces that io_uring handlers call into. As those are discovered and resolved, it should be just as (un)secure as the existing syscalls.

[jeisom]

This could make for easy performance testing to see how much of an impact it makes.