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

[microcode]

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

It's simple: it's an alternative syscall interface and not a special capability; the LSM hooks that deal with the underlying functionalities in the existing syscall interfaces should be sufficient, anything else is a bug.

[debrouxl]

This is an interesting, if belated, first step. However, a sysctl knob does not fix the fact that when io_uring is compiled in, the attack surface is present, and all it takes to access it again, even if it's disabled by the system administrator, is a memory write primitive...
Given the track record for io_uring, and the likelihood of not becoming airtight any time soon (expansion of functionality means expansion of attack surface, which cancels security fixing and hardening work), the default value really should be 1, if not 2. Backwards compatibility concerns will probably prevent the default usage of these settings by most distros... as well as a backport of this patch to all maintained stable releases which contain the io_uring infrastructure. Compatibility and speed are usually ranked higher than security

[markg85]

Ohh dammit!
So in the name of security, again, one of the best things happening to linux in the async io landscape is... being allowed to be disabled.
I bet that security minded (paranoia) distributions are going to disable this by default.

I hope normal distribution stay away from this new know. Aka, leave it enabled and as-is.

For those midgets that reply with "ohh but i like security" or "i better be safe so disable it please" or anything akin. You are entitled to your opinion, fine, use a distro that suits your views. Continue on.

[onlyLinuxLuvUBack]

Now if they could just make a way to disable systemd system-wide easily ?

[NotMine999]

So an interesting and proven useful new kernel feature is now being proven to have bugs...

And someone now contributes code to turn off said feature system-wide...

Sounds like the original developers of the useful feature ought to lose not only karma points but soul points over this one. Where is a healer when you need one?

[kylew77]

Compatibility and speed are usually ranked higher than security

One of the reasons I only run Linux for gaming and multimedia but OpenBSD for anything security conscious like banking and such. Linux and to a lesser strength FreeBSD chase the speed crown while OpenBSD and to a lesser extent NetBSD chase code correctness and security. Also, as much as I hate the rust language for being different from C, Redox OS looks interesting!

[intelfx]

This is an interesting, if belated, first step. However, a sysctl knob does not fix the fact that when io_uring is compiled in, the attack surface is present, and all it takes to access it again, even if it's disabled by the system administrator, is a memory write primitive...
Given the track record for io_uring, and the likelihood of not becoming airtight any time soon (expansion of functionality means expansion of attack surface, which cancels security fixing and hardening work), the default value really should be 1, if not 2. Backwards compatibility concerns will probably prevent the default usage of these settings by most distros... as well as a backport of this patch to all maintained stable releases which contain the io_uring infrastructure.

No, not backward compatibility concerns, but rather common sense concerns. If a feature becomes disabled-by-default everywhere, how exactly is it supposed to ever become airtight? If there are no users, there is no incentive to develop or maintain it any further.

Compatibility and speed are usually ranked higher than security

Security at the expense of any sort of progress is usually ranked quite low, that's for sure.

[coder]

This is an interesting, if belated, first step. However, a sysctl knob does not fix the fact that when io_uring is compiled in, the attack surface is present, and all it takes to access it again, even if it's disabled by the system administrator,

Then don't compile it in.

Given the track record for io_uring, and the likelihood of not becoming airtight any time soon

I'm getting the sense you're on some sort of jihad to get it expunged from the kernel sources, entirely. I think that's an overreaction. Give it a chance to settle in and see if they can shake out all of the vulnerabilities it hit. Either that, or you need to do a much better job of explaining why it's fundamentally insecure. None of this "guilt by extrapolation" crap.

the default value really should be 1, if not 2.

That would break software in the wild. Unless you can prove it's fundamentally insecure, then that's a nonstarter. If you can, then we shouldn't waste time with this band aid solution and it should just get ripped out.

[stormcrow]

I'm getting the sense you're on some sort of jihad to get it expunged from the kernel sources, entirely. I think that's an overreaction. Give it a chance to settle in and see if they can shake out all of the vulnerabilities it hit. Either that, or you need to do a much better job of explaining why it's fundamentally insecure. None of this "guilt by extrapolation" crap.

LWN wrote up an article on io_uring and specifically its issues when it comes to kernel auditing hooks in 2021 (absolutely required for certain security regimes). I don't know how current it is with regards to the most up-to-date Linus tree, but it's definitely relevant to the vast majority of businesses, governments, and universities who tend to ride stable kernels for long periods of time. Together they make up a huge chunk of the Linux user base, probably the majority between HPC, webservers, database servers, IoT, and Android devices. While it doesn't directly address your comment, it does take aim at what the people that built io_uring were looking at and especially what they weren't considering while creating it. Hence the problems we're now seeing coming out of io_uring (and by extension, other kernel subsystems touted to enhance performance or convenience but security wasn't considered - or worse, considered and rejected).

You personally may be able to poo-poo what's going on, that's fine, but you're only one person and any business that requires a focus on system security via internal policy or regulation is very much concerned about the problems with io_uring and probably already avoiding it by whatever means they can deploy on their systems. The only thing I hope Google remembered to do for the sysctl knob patch is to make it a read-only entry on running kernels.

[coder]

You personally may be able to poo-poo what's going on,

I didn't poo poo anything other than people trying to make statistical arguments. Sorry, you'll have to do better than that, if you want to break a kernel <-> userspace API. One of the only actual policies the kernel has about APIs is not to break the userspace API without good reason.

As for the idea of compiling it out and having a runtime switch to disable it, that's fair for people who don't feel they can tolerate the risk. The only thing I objected to was disabling it by default.

you're only one person

So are you.