Re: strace of io_uring events?

On 7/21/20 11:44 AM, Andy Lutomirski wrote:

On Tue, Jul 21, 2020 at 10:30 AM Jens Axboe [off-list ref] wrote:

quoted

On 7/21/20 11:23 AM, Andy Lutomirski wrote:

quoted

On Tue, Jul 21, 2020 at 8:31 AM Jens Axboe [off-list ref] wrote:

quoted

On 7/21/20 9:27 AM, 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.

How so?

Unless I've missed something, either current->mm or sqo_mm will be
used depending on which thread ends up doing the IO.  (And there might
be similar issues with threads.)  Having the user memory references
end up somewhere that is an implementation detail seems suboptimal.

current->mm is always used from the entering task - obviously if done
synchronously, but also if it needs to go async. The only exception is a
setup with SQPOLL, in which case ctx->sqo_mm is the task that set up the
ring. SQPOLL requires root privileges to setup, and there's no task
entering the io_uring at all necessarily. It'll just submit sqes with
the credentials that are registered with the ring.

Really?  I admit I haven't fully followed how the code works, but it
looks like anything that goes through the io_queue_async_work() path
will use sqo_mm, and can't most requests that end up blocking end up
there?  It looks like, even if SQPOLL is not set, the mm used will
depend on whether the request ends up blocking and thus getting queued
for later completion.

Or does some magic I missed make this a nonissue.

No, you are wrong. The logic works as I described it.

quoted

This is just one known use case, there may very well be others. Outside
of SQPOLL, which is special, I don't see a reason to restrict this.
Given that you may have a fuller understanding of it after the above
explanation, please clearly state what problem you're seeing that
warrants a change.

I see two fundamental issues:

1. The above.  This may be less of an issue than it seems to me, but,
if you submit io from outside sqo_mm, the mm that ends up being used
depends on whether the IO is completed from io_uring_enter() or from
the workqueue.  For something like Postgres, I guess this is okay
because the memory is MAP_ANONYMOUS | MAP_SHARED and the pointers all
point the same place regardless.

No that is incorrect. If you disregard SQPOLL, then the 'mm' is always
who submitted it.

2. If you create an io_uring and io_uring_enter() it from a different
mm, it's unclear what seccomp is supposed to do.  (Or audit, for that
matter.)  Which task did the IO?  Which mm did the IO?  Whose sandbox
is supposed to be applied?

Also doesn't seem like a problem, if you understand the 'mm' logic
above. Unless SQPOLL is used, the entering tasks mm will be used.
There's no mixing of tasks and mm outside of that.

-- 
Jens Axboe