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

11–20 of 66 posts

Re: Lord of the Io_uring (2020)

#11

Post by accelbred »

poincaredisk wrote: post #8
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…

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,…

Out of current ones, at a quick glance: connect, openat, openat2, renameat, mkdirat, and bind. More importantly, I'd like to block any opcode I haven't whitelisted, even when my software runs on future kernels with more opcodes available.

Now that I think about it, how does io_uring interact with landlock?

Re: Lord of the Io_uring (2020)

#12

Post by ibotty »

poincaredisk wrote: post #8
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…

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,…

It's not only potentially infested with vulnerabilities. It's also not possible to filter io_uring using seccomp at all. So if you allow io_uring, you allow all that is possible with it.

Re: Lord of the Io_uring (2020)

#13

Post by fweimer »

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.

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).

Re: Lord of the Io_uring (2020)

#14

Post by samlightfoot »

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…

https://github.com/containerd/containerd/issues/9048

Re: Lord of the Io_uring (2020)

#15

Post by alecco »

LAC-Tech wrote: post #9
mgaunard wrote: post #4

a lot of the functionality was significantly improved in 6 and isn't reflected there. In practice io_uring can be used in many different ways, and it can be challenging to find the most efficient one.

What are the big changes in 6? links welcome.

https://kernelnewbies.org/Linux_6.0#io_uring_features but only mentions zero copy and https://lwn.net/Articles/879724/

also https://www.phoronix.com/news/Linux-6.0-IO-Block-IO_uring

Re: Lord of the Io_uring (2020)

#16

Post by alecco »

jauntywundrkind wrote: post #2

Definitely one of the best pieces of documentation out there for io_uring. But I'm not sure how much if at all it's been updated since 2020 & Linux 5.5. https://web.archive.org/web/20200527021134/https://unixism.n...

Yeah, it should have (2020)

Previous discussion https://news.ycombinator.com/item?id=23132549

Re: Lord of the Io_uring (2020)

#17

Post by mahkoh »

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 descriptors where the blocking/non-blocking state of the file descriptions might be manipulated by an adversary at any time.

Re: Lord of the Io_uring (2020)

#18

Post by lukeh »

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…

Also useful for things like SPI with only blocking user space API.

Re: Lord of the Io_uring (2020)

#19

Post by fulafel »

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)

Post reply on HN