←back to thread

Waiting for many things at once with io_uring

(mazzo.li)
118 points ashvardanian | 1 comments | 14 Nov 24 12:04 UTC | HN request time: 0.208s | source
Show context
refulgentis ◴[18 Nov 24 20:45 UTC] No.42176793[source]▶
It took me many io_uring hello world articles to find out it's not really used in production (ex. Android and ChromeOS both disable it) because it was, and continues to be, a source of an absolutely bonkers outsized # of security issues.

I don't remember much more than that*, but just dropping it here because I learned a ton more from reading about that, than my Nth io_uring article.

* for example, the article mentioning relevant buffers are shared with the system made me want to say "aHA, yes, that's what the security articles said was a core issue!" -- but I can't actually remember with 100% confidence

replies(2): >>42177121 #>>42178527 #
MathMonkeyMan ◴[18 Nov 24 23:44 UTC] No.42178527[source]▶
Someone linked to a kernel mailing list recently, I don't know if it was in a submission or in a comment.

The security issue with io_uring, as I understand it, is that it bypasses a lot of Linux's security auditing mechanisms. The problem is that, like with ioctl, if the kernel called out to a security subsystem with "here's something that the user wants to do with this file," the security subsystem would have to know what "something" means for every driver. Impossible; so do you allow most things? Deny them? If you choose the former, now there are gaping security holes. If you choose the latter, then enabling security will break too many things.

replies(1): >>42179937 #
1. vacuity ◴[19 Nov 24 03:47 UTC] No.42179937[source]▶
We should have something like capability-based security, since object capabilities are amenable to more expressive interfaces than "read bytes" and "write bytes". Capability-based security also favors minimizing privilege by default instead of providing too much privilege and restricting/auditing later.