Very easy to just quote that without any io_uring experience.
> In June 2023, Google's security team reported that 60% of the exploits submitted to their bug bounty program in 2022 were exploits of the Linux kernel's io_uring vulnerabilities. As a result, io_uring was disabled for apps in Android, and disabled entirely in ChromeOS as well as Google servers. Docker also consequently disabled io_uring from their default seccomp profile.
> Although initial async offload design in io_uring could be problematic, later kernels changed the thread model. After such improvements, there were no known inherent problems with it and its development is very careful with new features. Considering that a performant async framework with a user facing API is complex, it was to be expected that issues would be found initially. After initial issues have been addressed, it is not any less secure than anything else in the kernel and io_uring acceptance quickly grew in production. Some of its criticism are also based on wrong or outdated assumptions.[14]
...but the only citation is a link to this GH thread, which doesn't support the claims made.
> How to handle people dismissing io_uring as insecure?
It is, in the general case, hard to prove something secure (because it's hard to prove a negative). It might help to show CVEs per month/year/whatever related to it vs anything else, preferably with a clear downward trend. For example, you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring ... although I struggle to read that as supporting the case you want to make.
> I have had to deal with handful of these people from different sectors as well. Since I am actively working on project based on io_uring, I have had people saying all kinds of hmm... "crap", its so baseless! Can't even talk to them with actual facts.
So what are those facts? Because all this thread has is people handwaving that it used to have a worse design, and everything has bugs and this isn't different, and implying that it's better. If it's better, show that.
I admit, I was confused a bit as well about the io_ring security reputation. Though I didn't really follow the topic, so the clarification that this was mostly about an older design on Android is quite helpful.
The potential performance benefits are quite compelling, e.g. in Postgres 18 you reportedly can get a 3x speedup over the old sync behaviour in simple read queries.
This is only true if people stick to a version of a language and don't upgrade.
If you upgrade then, for example, you can't run all of your PHP 5 code in PHP 8, most of it you can but you will have to change the parts that are broken, which are the areas that are repaired in PHP 8.
Maybe it is (mine is for sure) but that's a "bitten by the dog once" case.
You got bitten and everyone around you assures you won't get bitten again, but the pain was real and you still have a scar from the event. Why bother or invest risking another bite if there are other places to be which had never bitten before.
Over my career I hated technology 3 times. First was PHP, second was Python during Python 2/3 fiasco and third was CoffeeScript.
Edit: till this day one of my favorite meme is titled "PHP: Training wheels without a bike"
A few years ago, I used BTRFS on a laptop. Single disk, no RAID of any kind, OpenSUSE (which favored BTRFS, so I expected it to be as well supported as could be had), nothing fancy. After losing the root filesystem twice, I decided that maybe I shouldn't trust BTRFS. Since then, I've been told that it's totally better now, that all the problems are with bad RAID setups, and it's safe and won't lose my data. Anyways, as I type this from a laptop running on ZFS, I remain somewhat cautious.
MySQL would happily clobber your data silently for decades though.
I think the situation is better now, but that was worthy criticism for a long time; like anything though, those that bought into it wholeheartedly couldn’t take the criticisms.
I wonder if there’s a word for that, seems to be a common issue.
It’s true of most languages that have been around for a while. E.g. people who don’t write Javascript think of it as it was pre-ES6, not to mention that many people don’t write JS directly and use Typescript instead.
Same with Java, it’s somehow stuck in time in Java 6 in some people’s minds.
Wow. My view is stuck at php 4. Didn't even know 5 existed. I only remember Facebook making a big deal of hhvm and php 7 and laravel being considered great but not as great as rails or django.
I think it's the Wikipedia article.
https://en.wikipedia.org/wiki/Io_uring
Very easy to just quote that without any io_uring experience.
> In June 2023, Google's security team reported that 60% of the exploits submitted to their bug bounty program in 2022 were exploits of the Linux kernel's io_uring vulnerabilities. As a result, io_uring was disabled for apps in Android, and disabled entirely in ChromeOS as well as Google servers. Docker also consequently disabled io_uring from their default seccomp profile.
I like how someone helpfully added
> Although initial async offload design in io_uring could be problematic, later kernels changed the thread model. After such improvements, there were no known inherent problems with it and its development is very careful with new features. Considering that a performant async framework with a user facing API is complex, it was to be expected that issues would be found initially. After initial issues have been addressed, it is not any less secure than anything else in the kernel and io_uring acceptance quickly grew in production. Some of its criticism are also based on wrong or outdated assumptions.[14]
...but the only citation is a link to this GH thread, which doesn't support the claims made.
Jens Axboe replies on the very first line of the thread:
> As I'm sure you know, this is all mostly centered around a) google using an old kernel on android
> How to handle people dismissing io_uring as insecure?
It is, in the general case, hard to prove something secure (because it's hard to prove a negative). It might help to show CVEs per month/year/whatever related to it vs anything else, preferably with a clear downward trend. For example, you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring ... although I struggle to read that as supporting the case you want to make.
> I have had to deal with handful of these people from different sectors as well. Since I am actively working on project based on io_uring, I have had people saying all kinds of hmm... "crap", its so baseless! Can't even talk to them with actual facts.
So what are those facts? Because all this thread has is people handwaving that it used to have a worse design, and everything has bugs and this isn't different, and implying that it's better. If it's better, show that.
I admit, I was confused a bit as well about the io_ring security reputation. Though I didn't really follow the topic, so the clarification that this was mostly about an older design on Android is quite helpful.
The potential performance benefits are quite compelling, e.g. in Postgres 18 you reportedly can get a 3x speedup over the old sync behaviour in simple read queries.
It is kind of like PHP. Their views of PHP is still stuck at PHP 5. We have PHP 8.
Programming languages are different. They usually can't be "repaired" once broken, because they need to maintain backwards compatibility.
This is only true if people stick to a version of a language and don't upgrade.
If you upgrade then, for example, you can't run all of your PHP 5 code in PHP 8, most of it you can but you will have to change the parts that are broken, which are the areas that are repaired in PHP 8.
Same goes for other languages like C# or Python
Maybe it is (mine is for sure) but that's a "bitten by the dog once" case.
You got bitten and everyone around you assures you won't get bitten again, but the pain was real and you still have a scar from the event. Why bother or invest risking another bite if there are other places to be which had never bitten before.
Over my career I hated technology 3 times. First was PHP, second was Python during Python 2/3 fiasco and third was CoffeeScript.
Edit: till this day one of my favorite meme is titled "PHP: Training wheels without a bike"
A few years ago, I used BTRFS on a laptop. Single disk, no RAID of any kind, OpenSUSE (which favored BTRFS, so I expected it to be as well supported as could be had), nothing fancy. After losing the root filesystem twice, I decided that maybe I shouldn't trust BTRFS. Since then, I've been told that it's totally better now, that all the problems are with bad RAID setups, and it's safe and won't lose my data. Anyways, as I type this from a laptop running on ZFS, I remain somewhat cautious.
It's with so many things! Some evergreens just from last week here on HN:
- Rails is horribly slow!
- Python is still stuck migrating to Python 3!
- MySQL doesn't scale!
- Haskell tooling sucks!
- io_uring is insecure!
- ... and dozens more just in the programming world. These are just off the top of my head. Probably hundreds more in the wider engineering world.
MySQL would happily clobber your data silently for decades though.
I think the situation is better now, but that was worthy criticism for a long time; like anything though, those that bought into it wholeheartedly couldn’t take the criticisms.
I wonder if there’s a word for that, seems to be a common issue.
the work that the people in PHP did for 7 is criminally underrated
It’s true of most languages that have been around for a while. E.g. people who don’t write Javascript think of it as it was pre-ES6, not to mention that many people don’t write JS directly and use Typescript instead.
Same with Java, it’s somehow stuck in time in Java 6 in some people’s minds.
Wow. My view is stuck at php 4. Didn't even know 5 existed. I only remember Facebook making a big deal of hhvm and php 7 and laravel being considered great but not as great as rails or django.
> Perhaps if it had been written in Rust we would've been better off ;-).
So the answer is known :)
If you like to play around with io_uring networking, here is a very simple echo server example: https://github.com/frevib/io_uring-echo-server