3 ms·

Is io_uring still plagued by security issues enabled by it's use? Or have those largely been fixed? My understanding was many Linux admins (or even distros by d

by p_ing 1y ago

Is io_uring still plagued by security issues enabled by it's use? Or have those largely been fixed? My understanding was many Linux admins (or even distros by default?) were disabling io_uring.

hansvm 1y ago
https://github.com/axboe/liburing/discussions/1047 https://github.com/axboe/liburing/discussions/1047
- p_ing 1y ago
  Thanks. It looks like it is still going through growing pains. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://www.theregister.com/2025/04/29/linux_io_uring_security_flaw/?td=readmore https://www.theregister.com/2025/04/29/linux_io_uring_securi... But most of the 'off by default' are from ~2023 and not a current concern.
znpy 1y ago
Disabling io_uring because “guy on the internet said so” or “$faang_company says so” is beyond dumb. One should evaluate the risk according to their specific use case. It can be a good idea to disable it of you run untrusted workloads (eg: other people’s containers, sharing the same kernel) but if you have a kernel on a machine (virtual or real) dedicated to your own workload you can pretty much keep using io_uring. There are other technologies to enforce security (eg: selinux emand similar).
- wtallis 1y ago
  I think at this point, those "other technologies to enforce security" are the main area of concern for io_uring users: if those other security layers don't know about io_uring they won't apply any restrictions to it.
- p_ing 1y ago
  Yes, every security mechanism should be reviewed to validate it is applicable, i.e. I had a vulnerable version of node running but I wasn't using the particular aspect of node so it was a non-issue (and amazingly, IT sec agreed!). But in the case of io_uring, it was outright bypassing other security layers. And while we all like to think we're running trusted services/code, we have to think about supply-chain attacks that may surprise us, or zero days, etc.
- rdtsc 1y ago
  Oh sure, if you run your own server or sell your cloud as a service, you can enable it. But if you want to run on someone else’s setup, you have to play by their rules. > Disabling io_uring because “guy on the internet said so” or “$faang_company says so” is beyond dumb. I think it’s more like “$faang_company already disabled it in their hosts, so I am out of luck for my containers running on their cloud”
- lambdaone 1y ago
  Most users don't know what io_uring is, nor would they have read any of thosee articles. They are not HN readers with low-level understanding of operating systems workingm and don't even remotely have the knowledge of how any of these technologies work, nor do they have the time to get it. With a very few exceptions, users have to rely entirely on software vendors and service providers to do this for them, and trust they know what they're doing.

by p_ing 1y ago

Is io_uring still plagued by security issues enabled by it's use? Or have those largely been fixed? My understanding was many Linux admins (or even distros by default?) were disabling io_uring.

hansvm 1y ago

https://github.com/axboe/liburing/discussions/1047 https://github.com/axboe/liburing/discussions/1047

p_ing 1y ago
Thanks. It looks like it is still going through growing pains. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://www.theregister.com/2025/04/29/linux_io_uring_security_flaw/?td=readmore https://www.theregister.com/2025/04/29/linux_io_uring_securi... But most of the 'off by default' are from ~2023 and not a current concern.

znpy 1y ago

Disabling io_uring because “guy on the internet said so” or “$faang_company says so” is beyond dumb. One should evaluate the risk according to their specific use case. It can be a good idea to disable it of you run untrusted workloads (eg: other people’s containers, sharing the same kernel) but if you have a kernel on a machine (virtual or real) dedicated to your own workload you can pretty much keep using io_uring. There are other technologies to enforce security (eg: selinux emand similar).

wtallis 1y ago
I think at this point, those "other technologies to enforce security" are the main area of concern for io_uring users: if those other security layers don't know about io_uring they won't apply any restrictions to it.
p_ing 1y ago
Yes, every security mechanism should be reviewed to validate it is applicable, i.e. I had a vulnerable version of node running but I wasn't using the particular aspect of node so it was a non-issue (and amazingly, IT sec agreed!). But in the case of io_uring, it was outright bypassing other security layers. And while we all like to think we're running trusted services/code, we have to think about supply-chain attacks that may surprise us, or zero days, etc.
rdtsc 1y ago
Oh sure, if you run your own server or sell your cloud as a service, you can enable it. But if you want to run on someone else’s setup, you have to play by their rules. > Disabling io_uring because “guy on the internet said so” or “$faang_company says so” is beyond dumb. I think it’s more like “$faang_company already disabled it in their hosts, so I am out of luck for my containers running on their cloud”
lambdaone 1y ago
Most users don't know what io_uring is, nor would they have read any of thosee articles. They are not HN readers with low-level understanding of operating systems workingm and don't even remotely have the knowledge of how any of these technologies work, nor do they have the time to get it. With a very few exceptions, users have to rely entirely on software vendors and service providers to do this for them, and trust they know what they're doing.