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

51–60 of 66 posts

Re: Lord of the Io_uring (2020)

#51

Post by kragen »

accelbred wrote: post #43
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.…

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.

Interesting, I didn't realize inotify didn't work with FUSE. Is this a flaw in the FUSE interface, or is it just a deficiency in certain FUSE filesystems?

Re: Lord of the Io_uring (2020)

#52

Post by kragen »

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…

So does the FIONREAD ioctl, but it's not a general solution. (According to https://news.ycombinator.com/item?id=42617719, neither is io_uring yet.) Thanks for the link to the horrifying security problem!

Re: Lord of the Io_uring (2020)

#53

Post by kragen »

Sesse__ wrote: post #29
fweimer wrote: post #13

Earlier quoted context omitted.

GNU coreutils already has tons of Linux-specific code. But it would be a bit of a kernel fail if io_uring were faster or other preferable to copy_file_range for cp (at least for files that do not have holes).

Not at all; with io_uring, you can copy multiple files in parallel (and in fewer syscalls), which is a huge win for small files.

On a hard disk, copying multiple files in parallel is likely to make the copy run slower because it spends more time seeking back and forth between the files (except for small files). Perhaps that isn't a problem with SSDs? It seems like you'd still end up with the data from the different files interleaved in the erase blocks currently being written instead of contiguous, which seems like it would slow down all subsequent reads of those files (unless they're less than a page in size).

Re: Lord of the Io_uring (2020)

#54

Post by cmrdporcupine »

fulafel wrote: post #19
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…

Does this mean you shouldn't use it in containers? edit: it does seem it is disabled there now: https://github.com/containerd/containerd/pull/9320 (thanks to sibling comment for an adjancent link)

Yeah I had code at one point in my hobby project that used io_uring and it stopped working in docker without overriding security restrictions.

Unfortunately decided it's not worth it.

Re: Lord of the Io_uring (2020)

#55

Post by jefftk »

kragen wrote: post #51
accelbred wrote: post #43

Earlier quoted context omitted.

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.

Interesting, I didn't realize inotify didn't work with FUSE. Is this a flaw in the FUSE interface, or is it just a deficiency in certain FUSE filesystems?

I think the key problem is that mapping from FUSE requests to inotify events requires information that only the FUSE daemon has. For example, lets say you open a file with O_CREAT. Whether this should trigger IN_CREATE depends on whether the file already exists. The kernel doesn't know this, and so couldn't be responsible for generating the IN_CREATE event.

Now, the FUSE daemon could generate the event, but correctly generating events (especially handling edge cases) is difficult.

Re: Lord of the Io_uring (2020)

#56

Post by burch45 »

accelbred wrote: post #41
quotemstr wrote: post #36

Earlier quoted context omitted.

> 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?

Parent is referring to https://en.m.wikipedia.org/wiki/Mandatory_access_control As opposed to https://en.m.wikipedia.org/wiki/Medium_access_control

Re: Lord of the Io_uring (2020)

#57

Post by dvektor »

I was actually glued to that page for a few days recently, it's a great write-up.

io_uring is such a tremendous improvement over epoll, in both speed and user experience. With sqpoll, vectored ops and proper batching you can get some crazyy speed. I am definitely looking forward to seeing some of these seccomp and privilege issues getting fixed and getting container support in the future.

Re: Lord of the Io_uring (2020)

#59

Post by immibis »

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…

seccomp is a mitigation. Once you have already been exploited, if further escalation is prevented by seccomp, or ASLR, or NX stack, or ....... then you got lucky.

Re: Lord of the Io_uring (2020)

#60

Post by fulafel »

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…

SELinux is a dx/ux hostile nightmare that we definitely shouldn't be springing on everybody.
Post reply on HN