[flagged]
Lord of the Io_uring (2020)
21–30 of 66 posts
Re: Lord of the Io_uring (2020)
#22Re: Lord of the Io_uring (2020)
#23I'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,…
> 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 that it's still trying to shake.
Re: Lord of the Io_uring (2020)
#24[flagged]
Windows has copied io_uring from Linux.
Re: Lord of the Io_uring (2020)
#25I'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. See REGISTER_RESTRICTIONS in the documentation. Any process that's setting up its own seccomp restrictions can also set up a uring with restrictions, limiting the opcodes it can use.
That said, that mechanism would benefit from a way to apply such restrictions to a process that isn't doing the setup itself, such as when setting up seccomp restrictions on a container or daemon. 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.
Re: Lord of the Io_uring (2020)
#26Re: Lord of the Io_uring (2020)
#27Earlier quoted context omitted.
Windows has copied io_uring from Linux.
This is a troll, but NT did indeed support async IO via WaitForMultipleObjects in the late 90s, long before Linux had a good async IO story.
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.
Re: Lord of the Io_uring (2020)
#28Earlier quoted context omitted.
This is a troll, but NT did indeed support async IO via WaitForMultipleObjects in the late 90s, long before Linux had a good async IO story.
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...
Re: Lord of the Io_uring (2020)
#29There 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).
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.
Re: Lord of the Io_uring (2020)
#30This document helped me learn the io_uring API.
You can use io_uring with epoll to monitor eventfd to wake up your sleeping with io_uring wait for completions.
I have implemented a barrier and thread safe techniques that I am trying to turn into a command line tool
My goal is that thread safe performant servers are easy to write.
I am using bloom filters for fast set intersection. I intend to use Simd instructions with the bloom hashes.