I don't think your run often into these things, because of Rust's ownership enforcement. But I might be misunderstanding you, because it's all pretty abstract and I might not have the whole context.
There is relatively little Rust in the kernel, but there are even less Rust CVEs. In this cycle alone there were 160 CVEs, one in Rust. The first one! The amount of rust is way less than 1/160 and even that statistic is off, because one should count all CVEs.
That is debatable, and I think untrue. It sometimes takes years to find CVEs in C code, and I don’t know of an argument why that would be different for Rust.
The fairest comparison, I think, would be with other new code of similar complexity in the kernel, and track #of CVEs per equivalent functionality (per line of code might be sufficient, but if one language is verbose than the other, you should correct for that)
One problem is that you can't filter its "syscalls" as you can regular syscalls. This removes a security boundary that e.g. container runtimes regularly use. So you cannot use it in your regular kubernetes cluster without weakening its security for these pods.
This just reinforces the (maybe unfounded) impression that security is a secondary consideration, and performance is primary.
I'd use io_uring in a heartbeat on a dedicated system where the job is only I/O and security isolation isn't a concern. But multiuser/multiapplication/networked? Not a chance.
I think there is a very large amount of overlap between the people who
1. know what io_uring is
2. are interested in performance enough to look at improvements based on new linux kernel system calls and talk about it in public
3. care about security in multitenant environments or the syscalls used by third party libraries
I think io_uring right now probably makes a lot of sense for HPC and highly technical, performance-sensitive financial stuff, but they can be kind of insular. I don't think most linux hobbyists really need the performance benefits enough t care about it, and most businesses are using a major cloud vendor/don't have the scale or expertise to be thinking about this kind of stuff. Which leaves major cloud providers and really big businesses like Meta with their own internal clouds as the ones that stand to benefit enough to care about performance while really caring about security
For me it's less about performance than cleaner concurrency. Do you know (unless this has been fixed recently) that io_uring is the only way you can asynchronously open a file? Erlang and GHC both have lightweight threads/processes that use asynchronous i/o (for sockets, say), but they keep a separate OS threadpool to be able to do stuff like open files. io_uring lets you write an actual multitasking OS-like thing that runs in a single Linux thread.
Yup, but that leads to io-uring devs complaining that people dislike software using io-uring because it doesn't run in containers/etc blocking io-uring entirely
Isn't the issue here just that io_uring needs to be enhanced such that, when a seccomp-bpf filter is installed, the filter gets called to approve each SQE, before it gets executed?
- io_uring initially was conceived without considering security or auditing tools
- io_uring later was changed to allow ioctl calls, even though security people do not like ioctl because what its arguments mean depends on the device being called (possibly even on the version of the driver), not on the type of device, and often is poorly documented, making it hard for a security filter to decide what to do with a command.
That also made them fear that similar security-breaking changes might be made in the future.
I don't think this is an appropriate use of "just". If io_uring doesn't work with seccomp-bpf filters today, there are many situations where you just can't use it, period.
That someone with kernel IO dev experience may be able to relatively easily add such a fetaure in the future (though I would doubt that, given that it hasn't yet been implemented apparently) doesn't make it a small problem.
seccomp BPF, eBPF, in a way SELinux/AppArmor/Tomoyo/..., maybe you can even call namespaces some kind of syscall filter. And then there is the auditing framework, where you can at least record which critical syscalls were performed.
Nowadays its mostly a combination of eBPF, SELinux and auditd plus namespaces in case of containers. Usually in the combination that some distro ships, so nothing really fancy.
This would be something the Boomer generation grew up with, and I think maybe the previous generation too. They're still around but they've certainly faded; they used to be Lego-level popular kids toys back then. They are named after President Lincoln, but only as a marketing tactic to use some of his reputation, there's no real connection.
I would imagine even some native English speakers are learning something with this post. I haven't seen them in a while.
There’s a strong connection between President Lincoln and log cabins. He grew up in a series of log cabins, and this fact was widely known during his campaign.
I'm a late millennial, and I'd sometimes see them as a kid too. I'm not sure about more recent generations, but I think that they might have stuck around longer than you might think.
> They were named after President Lincoln, but only as a marketing tactic
> there's no real connection
Funny--I always thought it was meant to be a pun on linkin', as in you're linkin' the logs together because they have those slots that fit precisely together on the ends.
I think it's both that and the popular tale of Lincoln having been born in a log cabin (which for some reason I thought I had heard wasn't actually true, but from looking into it now, it seems like a lot of sources say it is, so maybe I heard wrong?)
They were still pretty common when I was a kid in the early '80s. genX'ers and older millennials born in the US are likely to know about them, or perhaps even have had a set of them (I did).
