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

31–40 of 66 posts

Re: Lord of the Io_uring (2020)

#31

Post by p_ing »

JoshTriplett wrote: post #28
p_ing wrote: post #27

Earlier quoted context omitted.

I don't think it's a troll (though not a particularly useful comment); Linux has had no true async story thus far. poll, epoll, et. al. are all synchronous behind-the-scenes. What Linux still lacks is an OVERLAPPED data structure. NT has supported async I/O since it's inception. It was a design principle of the kernel -- all I/O operations in the kernel are async'ed.

I wasn't referring to async I/O. I'm talking about the ability to make system calls using a user/kernel shared memory buffer, without having to enter and exit the kernel. (This is particularly important with all the security mitigations that make kernel entry/exit more expensive.) https://windows-internals.com/ioring-vs-io_uring-a-compariso...

Technically Windows has Registered I/O in Windows 8/Server 2012 for networking which provided this functionality. I/O Rings in Windows extended this to other types of I/O, but of course with a separate API.

https://serverframework.com/asynchronousevents/2011/10/windo...

So if we're talking about concepts... NT first, again ;-)

Re: Lord of the Io_uring (2020)

#35

Post by alexgartrell »

Thaxll wrote: post #32

Someone can comment on the security implications of sharing a buffer between user space and kernel space?

Sharing a queue itself is not new https://www.kernel.org/doc/html/v5.8/networking/packet_mmap.... and https://docs.kernel.org/next/userspace-api/perf_ring_buffer.... are two examples.

Issues with io_uring security mostly stemmed from an old architecture and just the fact that there's a ton of surface area.

Re: Lord of the Io_uring (2020)

#36

Post by quotemstr »

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 from some file but not write to it, you should do that with real MAC, which applies to all operations , il_uring included. You shouldn't just filter read(2) and write(2) in particular.

We shouldn't hold back evolution in systems interfaces because some people are stuck on bad ways of doing things and won't move.

Re: Lord of the Io_uring (2020)

#37

Post by quotemstr »

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

> For instance, a way to set restrictions on all rings created by child processes, or a way for seccomp to enforce that any uring created has restrictions applied to it.

SELinux or your favorite MAC is there to solve this exact problem.

Re: Lord of the Io_uring (2020)

#38

Post by quotemstr »

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…

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

Re: Lord of the Io_uring (2020)

#39

Post by quotemstr »

Thaxll wrote: post #32

Someone can comment on the security implications of sharing a buffer between user space and kernel space?

binder shares a buffer between kernel and user space on billions of Android devices, and Android is by far the most secure Linux distribution.

There's nothing wrong with the general concept.

Post reply on HN