On 7/21/20 9:27 AM, Andy Lutomirski wrote: > On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella <sgarzare@xxxxxxxxxx> wrote: >> >> On Thu, Jul 16, 2020 at 08:12:35AM -0700, Kees Cook wrote: >>> On Thu, Jul 16, 2020 at 03:14:04PM +0200, Stefano Garzarella wrote: > >>> 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. How so? > 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 That'll break postgres that already uses this, also see: commit 73e08e711d9c1d79fae01daed4b0e1fee5f8a275 Author: Jens Axboe <axboe@xxxxxxxxx> Date: Sun Jan 26 09:53:12 2020 -0700 Revert "io_uring: only allow submit from owning task" So no, we can't do that. -- Jens Axboe