Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lord of the Io_uring (2020)

unixism.net

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Lord of the Io_uring (2020)

#41

Post by accelbred »

quotemstr wrote: post #36
accelbred wrote: post #6

I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well jus…

> find it annoying when kernel APIs like ublk require io_uring Good. That's a forcing function for making io_uring work in your environment. > bypasses seccomp Seccomp sucks. We shouldn't be enforcing security by filtering system calls, the set of which will grow forever, but instead by describing access control rules on objects, e.g. with SELinux. If your security policy is that your sandbox should be able to read f…

Since when can you use a MAC as an unprivileged user on an arbitrary distro?

Re: Lord of the Io_uring (2020)

#42

Post by haberman »

JoshTriplett wrote: post #25
accelbred wrote: post #6

I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well jus…

ublk, specifically, is something I'd expect to be primarily used in privileged contexts anyway, because the primary use of the resulting block device is to mount it, which requires privileges for most interesting filesystems. If you want an unprivileged mechanism, you may be interested in the upcoming uring-accelerated FUSE support. For other uses, uring has a "restriction" mechanism that does part of what you want.…

> you may be interested in the upcoming uring-accelerated FUSE support.

Do you have a reference for this? What is the anticipated timeframe?

Re: Lord of the Io_uring (2020)

#43

Post by accelbred »

JoshTriplett wrote: post #25
accelbred wrote: post #6

I'd like to use io_uring, but as long as it bypasses seccomp it should be disabled whenever seccomp is in use. As such, I use epoll, and find it annoying when kernel APIs like ublk require io_uring. The places I'd want to use ublk are inside sandboxes using seccomp. Given that container runtimes, hardened kernels, chromeos, etc., disable io_uring, using it means needing an epoll fallback anyways, so might as well jus…

ublk, specifically, is something I'd expect to be primarily used in privileged contexts anyway, because the primary use of the resulting block device is to mount it, which requires privileges for most interesting filesystems. If you want an unprivileged mechanism, you may be interested in the upcoming uring-accelerated FUSE support. For other uses, uring has a "restriction" mechanism that does part of what you want.…

The main problem I have with fuse is inotify not working. If inotify just worked for fuse, I'd just use it. Ideally I could just run the software in a mount namespace with a fuse fs, but I need inotify.

I mainly was trying to use ublk to implement a sort of fuse like thing with the kernel handling the fs and thus having inotify support.

Re: Lord of the Io_uring (2020)

#44

Post by JoshTriplett »

haberman wrote: post #42
JoshTriplett wrote: post #25

Earlier quoted context omitted.

ublk, specifically, is something I'd expect to be primarily used in privileged contexts anyway, because the primary use of the resulting block device is to mount it, which requires privileges for most interesting filesystems. If you want an unprivileged mechanism, you may be interested in the upcoming uring-accelerated FUSE support. For other uses, uring has a "restriction" mechanism that does part of what you want.…

> you may be interested in the upcoming uring-accelerated FUSE support. Do you have a reference for this? What is the anticipated timeframe?

https://lore.kernel.org/io-uring/20241209-fuse-uring-for-6-1...

I don't know when it'll be merged, but it seems like it's getting close to ready.

Re: Lord of the Io_uring (2020)

#45

Post by dietr1ch »

quotemstr wrote: post #38
JoshTriplett wrote: post #23

Earlier quoted context omitted.

> infested with vulnerabilities Current io_uring is not particularly prone to vulnerabilities. The original version of it had a design that often led to them (a kernel thread doing operations on behalf of the process and not always remembering to set the appropriate privileges), but it no longer uses that design, and the current design is much more resilient. Unfortunately, the original design led to a reputation tha…

> Current io_uring is not particularly prone to vulnerabilities The tech industry: launch early! Develop in public! Many eyes make all bugs shallow! Also the tech industry: we will never forgive you for that one segfault you had ten years ago.

Remember that 10yo crash? Well, I'm going to use a 12yo kernel and complain about it.

Re: Lord of the Io_uring (2020)

#46

Post by o11c »

mahkoh wrote: post #17
t00 wrote: post #7

There are examples of cat and cp using io_uring. What are the chances of having io_uring utilised by standard commands to improve overall Linux performance? I presume GNU utils are not Linux specific hence such commands are programmed for a generic *nix. Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll.

>Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll. One of the advantages of io_uring, unrelated to performance, is that it supports non-blocking operations on blocking file descriptors. Using io_uring is the only method I recall to bypass https://gitlab.freedesktop.org/wayland/wayland/-/issues/296 . This issue deals with having to operate on untrusted file…

I thought for sure this was wrong, but when I actually checked the docs, it turns out that `RWF_NOWAIT` is only valid for `preadv2` not `pwritev2`. This should probably be fixed.

For sockets, `MSG_DONTWAIT` works with both `recv` and `send`.

For pipes you should be able to do this with `SPLICE_F_NONBLOCK` and the `splice` family, but there are weird restrictions for those.

Re: Lord of the Io_uring (2020)

#47

Post by saghm »

I'm realizing from the title of this that the intended pronunciation of "uring" is probably "yoo-ring"; for some reason I had mentally been reading it as "yurr-ring" all this time, and I guess I never heard anyone say it out loud before. In retrospect, I probably could have guessed that I might be missing something given that I had no clue what "uring" was supposed to mean.

Re: Lord of the Io_uring (2020)

#48

Post by [deleted] »

dietr1ch wrote: post #45
quotemstr wrote: post #38

Earlier quoted context omitted.

> Current io_uring is not particularly prone to vulnerabilities The tech industry: launch early! Develop in public! Many eyes make all bugs shallow! Also the tech industry: we will never forgive you for that one segfault you had ten years ago.

Remember that 10yo crash? Well, I'm going to use a 12yo kernel and complain about it.

[deleted]

Re: Lord of the Io_uring (2020)

#49

Post by poincaredisk »

quotemstr wrote: post #38
JoshTriplett wrote: post #23

Earlier quoted context omitted.

> infested with vulnerabilities Current io_uring is not particularly prone to vulnerabilities. The original version of it had a design that often led to them (a kernel thread doing operations on behalf of the process and not always remembering to set the appropriate privileges), but it no longer uses that design, and the current design is much more resilient. Unfortunately, the original design led to a reputation tha…

> Current io_uring is not particularly prone to vulnerabilities The tech industry: launch early! Develop in public! Many eyes make all bugs shallow! Also the tech industry: we will never forgive you for that one segfault you had ten years ago.

Excuse me? Io_uring is by far the most often exploited syscall on modern day Linux. Most often exploited subsystem even. https://www.phoronix.com/news/Google-Restricting-IO_uring

Re: Lord of the Io_uring (2020)

#50

Post by poincaredisk »

JoshTriplett wrote: post #23
poincaredisk wrote: post #8

Earlier quoted context omitted.

Is there a specific io_uring opcode you would like disabled in your sandboxes? It's not like io_uring is a complete seccomp bypass, just another syscall that provides an alternative way to do many things. I doubt you block "read" or "accept" in docker, for example. You can't execute a sysctl or mount a filesystem using io_uring, which are things that are actually blocked in Docker by default. edit: on the other hand,…

> infested with vulnerabilities Current io_uring is not particularly prone to vulnerabilities. The original version of it had a design that often led to them (a kernel thread doing operations on behalf of the process and not always remembering to set the appropriate privileges), but it no longer uses that design, and the current design is much more resilient. Unfortunately, the original design led to a reputation tha…

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring

20 CVEs in 2024. Yes, some of them are not (exploitable) vulnerabilities, probably, because Linux CNA is being difficult. But many of them are, just ctrl+f privilege.

Post reply on HN