Re: strace of io_uring events?

On Tue, Jul 21, 2020 at 05:58:48PM +0200, Stefano Garzarella wrote:

On Tue, Jul 21, 2020 at 08:27:34AM -0700, Andy Lutomirski wrote:

quoted

On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella [off-list ref] wrote:

quoted

On Thu, Jul 16, 2020 at 08:12:35AM -0700, Kees Cook wrote:

quoted

On Thu, Jul 16, 2020 at 03:14:04PM +0200, Stefano Garzarella wrote:

quoted

quoted

access (IIUC) is possible without actually calling any of the io_uring
syscalls. Is that correct? A process would receive an fd (via SCM_RIGHTS,
pidfd_getfd, or soon seccomp addfd), and then call mmap() on it to gain
access to the SQ and CQ, and off it goes? (The only glitch I see is
waking up the worker thread?)

It is true only if the io_uring istance is created with SQPOLL flag (not the
default behaviour and it requires CAP_SYS_ADMIN). In this case the
kthread is created and you can also set an higher idle time for it, so
also the waking up syscall can be avoided.

I stared at the io_uring code for a while, and I'm wondering if we're
approaching this the wrong way. It seems to me that most of the
complications here come from the fact that io_uring SQEs don't clearly
belong to any particular security principle.  (We have struct creds,
but we don't really have a task or mm.)  But I'm also not convinced
that io_uring actually supports cross-mm submission except by accident
-- as it stands, unless a user is very careful to only submit SQEs
that don't use user pointers, the results will be unpredictable.
Perhaps we can get away with this:

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 74bc4a04befa..92266f869174 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c

@@ -7660,6 +7660,20 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int,

fd, u32, to_submit,
     if (!percpu_ref_tryget(&ctx->refs))
         goto out_fput;

+    if (unlikely(current->mm != ctx->sqo_mm)) {
+        /*
+         * The mm used to process SQEs will be current->mm or
+         * ctx->sqo_mm depending on which submission path is used.
+         * It's also unclear who is responsible for an SQE submitted
+         * out-of-process from a security and auditing perspective.
+         *
+         * Until a real usecase emerges and there are clear semantics
+         * for out-of-process submission, disallow it.
+         */
+        ret = -EACCES;
+        goto out;
+    }
+
     /*
      * For SQ polling, the thread will do all submissions and completions.
      * Just return the requested submit count, and wake the thread if

If we can do that, then we could bind seccomp-like io_uring filters to
an mm, and we get obvious semantics that ought to cover most of the
bases.

Jens, Christoph?

Stefano, what's your intended usecase for your restriction patchset?

Hi Andy,
my use case concerns virtualization. The idea, that I described in the
proposal of io-uring restrictions [1], is to share io_uring CQ and SQ queues
with a guest VM for block operations.

In the PoC that I realized, there is a block device driver in the guest that
uses io_uring queues coming from the host to submit block requests.

Since the guest is not trusted, we need restrictions to allow only
a subset of syscalls on a subset of file descriptors and memory.

BTW there's only a single mm in the kvm.ko use case.

Stefan