public inbox for [email protected]
 help / color / mirror / Atom feed
From: Andy Lutomirski <[email protected]>
To: Jens Axboe <[email protected]>, Andres Freund <[email protected]>
Cc: Andy Lutomirski <[email protected]>,
	Stefano Garzarella <[email protected]>,
	Christoph Hellwig <[email protected]>, Kees Cook <[email protected]>,
	Pavel Begunkov <[email protected]>,
	Miklos Szeredi <[email protected]>,
	Matthew Wilcox <[email protected]>,
	Jann Horn <[email protected]>,
	Christian Brauner <[email protected]>,
	[email protected], [email protected],
	Linux API <[email protected]>,
	Linux FS Devel <[email protected]>,
	LKML <[email protected]>,
	Michael Kerrisk <[email protected]>,
	Stefan Hajnoczi <[email protected]>
Subject: Re: strace of io_uring events?
Date: Tue, 21 Jul 2020 10:23:22 -0700	[thread overview]
Message-ID: <CALCETrXAxFzuRB5EJZR7bbgfrEcNc=9_E7wwhPaZ3YGJ1=DZ0w@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Tue, Jul 21, 2020 at 8:31 AM Jens Axboe <[email protected]> wrote:
>
> On 7/21/20 9:27 AM, Andy Lutomirski wrote:
> > On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella <[email protected]> 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?

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.

>
> > 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 <[email protected]>
> 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.
>

Yikes, I missed that.

Andres, how final is your Postgres branch?  I'm wondering if we could
get away with requiring a special flag when creating an io_uring to
indicate that you intend to submit IO from outside the creating mm.

Even if we can't make this change, we could plausibly get away with
tying seccomp-style filtering to sqo_mm.  IOW we'd look up a
hypothetical sqo_mm->io_uring_filters to filter SQEs even when
submitted from a different mm.

--Andy

  reply	other threads:[~2020-07-21 17:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 11:12 strace of io_uring events? Miklos Szeredi
2020-07-15 14:35 ` Andy Lutomirski
2020-07-15 17:11   ` Matthew Wilcox
2020-07-15 19:42     ` Pavel Begunkov
2020-07-15 20:09       ` Miklos Szeredi
2020-07-15 20:20         ` Pavel Begunkov
2020-07-15 23:07           ` Kees Cook
2020-07-16 13:14             ` Stefano Garzarella
2020-07-16 15:12               ` Kees Cook
2020-07-17  8:01                 ` Stefano Garzarella
2020-07-21 15:27                   ` Andy Lutomirski
2020-07-21 15:31                     ` Jens Axboe
2020-07-21 17:23                       ` Andy Lutomirski [this message]
2020-07-21 17:30                         ` Jens Axboe
2020-07-21 17:44                           ` Andy Lutomirski
2020-07-21 18:39                             ` Jens Axboe
2020-07-21 19:44                               ` Andy Lutomirski
2020-07-21 19:48                                 ` Jens Axboe
2020-07-21 19:56                                 ` Andres Freund
2020-07-21 19:37                         ` Andres Freund
2020-07-21 15:58                     ` Stefano Garzarella
2020-07-23 10:39                       ` Stefan Hajnoczi
2020-07-23 13:37                       ` Colin Walters
2020-07-24  7:25                         ` Stefano Garzarella
2020-07-16 13:17             ` Aleksa Sarai
2020-07-16 15:19               ` Kees Cook
2020-07-17  8:17               ` Cyril Hrubis
2020-07-16 16:24             ` Andy Lutomirski
2020-07-16  0:12     ` tytso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALCETrXAxFzuRB5EJZR7bbgfrEcNc=9_E7wwhPaZ3YGJ1=DZ0w@mail.gmail.com' \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox