Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Aleksa Sarai <cyphar@cyphar.com>
To: Kees Cook <keescook@chromium.org>
Cc: Pavel Begunkov <asml.silence@gmail.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Matthew Wilcox <willy@infradead.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Jann Horn <jannh@google.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	strace-devel@lists.strace.io, io-uring@vger.kernel.org,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: strace of io_uring events?
Date: Thu, 16 Jul 2020 23:17:55 +1000	[thread overview]
Message-ID: <20200716131755.l5tsyhupimpinlfi@yavin.dot.cyphar.com> (raw)
In-Reply-To: <202007151511.2AA7718@keescook>

[-- Attachment #1: Type: text/plain, Size: 4849 bytes --]

On 2020-07-15, Kees Cook <keescook@chromium.org> wrote:
> Earlier Andy Lutomirski wrote:
> > Let’s add some seccomp folks. We probably also want to be able to run
> > seccomp-like filters on io_uring requests. So maybe io_uring should call into
> > seccomp-and-tracing code for each action.
> 
> Okay, I'm finally able to spend time looking at this. And thank you to
> the many people that CCed me into this and earlier discussions (at least
> Jann, Christian, and Andy).
> 
> It *seems* like there is a really clean mapping of SQE OPs to syscalls.
> To that end, yes, it should be trivial to add ptrace and seccomp support
> (sort of). The trouble comes for doing _interception_, which is how both
> ptrace and seccomp are designed.
> 
> In the basic case of seccomp, various syscalls are just being checked
> for accept/reject. It seems like that would be easy to wire up. For the
> more ptrace-y things (SECCOMP_RET_TRAP, SECCOMP_RET_USER_NOTIF, etc),
> I think any such results would need to be "upgraded" to "reject". Things
> are a bit complex in that seccomp's form of "reject" can be "return
> errno" (easy) or it can be "kill thread (or thread_group)" which ...
> becomes less clear. (More on this later.)
> 
> In the basic case of "I want to run strace", this is really just a
> creative use of ptrace in that interception is being used only for
> reporting. Does ptrace need to grow a way to create/attach an io_uring
> eventfd? Or should there be an entirely different tool for
> administrative analysis of io_uring events (kind of how disk IO can be
> monitored)?

I would hope that we wouldn't introduce ptrace to io_uring, because
unless we plan to attach to io_uring events via GDB it's simply the
wrong tool for the job. strace does use ptrace, but that's mostly
because Linux's dynamic tracing was still in its infancy at the time
(and even today it requires more privileges than ptrace) -- but you can
emulate strace using bpftrace these days fairly easily.

So really what is being asked here is "can we make it possible to debug
io_uring programs as easily as traditional I/O programs". And this does
not require ptrace, nor should ptrace be part of this discussion IMHO. I
believe this issue (along with seccomp-style filtering) have been
mentioned informally in the past, but I am happy to finally see a thread
about this appear.

> For io_uring generally, I have a few comments/questions:
> 
> - Why did a new syscall get added that couldn't be extended? All new
>   syscalls should be using Extended Arguments. :(

io_uring was introduced in Linux 5.1, predating clone3() and openat2().
My larger concern is that io_uring operations aren't extensible-structs
-- but we can resolve that issue with some slight ugliness if we ever
run into the problem.

> - Why aren't the io_uring syscalls in the man-page git? (It seems like
>   they're in liburing, but that's should document the _library_ not the
>   syscalls, yes?)

I imagine because using the syscall requires specific memory barriers
which we probably don't want most C programs to be fiddling with
directly. Sort of similar to how iptables doesn't have a syscall-style
man page.

> Speaking to Stefano's proposal[1]:
> 
> - There appear to be three classes of desired restrictions:
>   - opcodes for io_uring_register() (which can be enforced entirely with
>     seccomp right now).
>   - opcodes from SQEs (this _could_ be intercepted by seccomp, but is
>     not currently written)
>   - opcodes of the types of restrictions to restrict... for making sure
>     things can't be changed after being set? seccomp already enforces
>     that kind of "can only be made stricter"

Unless I misunderstood the patch cover-letter, Stefano's proposal is to
have a mechanism for adding restrictions to individual io_urings -- so
we still need a separate mechanism (or an extended version of Stefano's
proposal) to allow for the "reduce attack surface" usecase of seccomp.
It seems to me like Stefano's proposal is more related to cases where
you might SCM_RIGHTS-send an io_uring to an unprivileged process.

> Solving the mapping of seccomp interception types into CQEs (or anything
> more severe) will likely inform what it would mean to map ptrace events
> to CQEs. So, I think they're related, and we should get seccomp hooked
> up right away, and that might help us see how (if) ptrace should be
> attached.

We could just emulate the seccomp-bpf API with the pseudo-syscalls done
as a result of CQEs, though I'm not sure how happy folks will be with
this kind of glue code in "seccomp-uring" (though in theory it would
allow us to attach existing filters to io_uring...).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2020-07-16 13:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 11:12 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
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 [this message]
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=20200716131755.l5tsyhupimpinlfi@yavin.dot.cyphar.com \
    --to=cyphar@cyphar.com \
    --cc=asml.silence@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=io-uring@vger.kernel.org \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=miklos@szeredi.hu \
    --cc=mtk.manpages@gmail.com \
    --cc=sgarzare@redhat.com \
    --cc=strace-devel@lists.strace.io \
    --cc=willy@infradead.org \
    --subject='Re: strace of io_uring events?' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).