Re: strace of io_uring events?
flat view
From: Jens Axboe <axboe@kernel.dk>
Date: 2020-07-21 15:32:01
Also in:
io-uring, linux-fsdevel, lkml
On 7/21/20 9:27 AM, Andy Lutomirski wrote:
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?
quoted hunk ↗ jump to hunk
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 [off-list ref]
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