←back to thread

118 points ashvardanian | 4 comments | | HN request time: 0.794s | source
1. jeffbee ◴[] No.42175397[source]
Some of the things that you cannot wait on using io_uring are your kernel actually supporting the feature mentioned in the article, io_uring actually working properly, and io_uring solving its seemingly bottomless supply of local user exploits. In the early days of this feature I was bullish but the way its implementation has emitted CVEs has not been a source of joy, and now many major Linux operators have banned the API internally. Maybe what is needed is a moment of reflection and a scratch reimplementation that learns the lessons of io_uring?
replies(2): >>42176924 #>>42177157 #
2. ◴[] No.42176924[source]
3. loeg ◴[] No.42177157[source]
A new from-scratch implementation would suffer from a similar problem as early io_uring did (high rate of code change, which seems to be what drives security bug rates).
replies(1): >>42178630 #
4. KerrAvon ◴[] No.42178630[source]
Isn't something fundamentally broken with either the kernel or the adoption process if that's true? It seems like you should be able to do fast async I/O without the kind of privilege escalation vulnerabilities that are still happening.