From: Kees Cook <[email protected]>
To: Aleksa Sarai <[email protected]>
Cc: Pavel Begunkov <[email protected]>,
Miklos Szeredi <[email protected]>,
Matthew Wilcox <[email protected]>,
Andy Lutomirski <[email protected]>,
Jann Horn <[email protected]>,
Stefano Garzarella <[email protected]>,
Christian Brauner <[email protected]>,
[email protected], [email protected],
Linux API <[email protected]>,
[email protected], [email protected],
Michael Kerrisk <[email protected]>,
Stefan Hajnoczi <[email protected]>
Subject: Re: strace of io_uring events?
Date: Thu, 16 Jul 2020 08:19:34 -0700 [thread overview]
Message-ID: <202007160812.A8D43ABBBE@keescook> (raw)
In-Reply-To: <[email protected]>
On Thu, Jul 16, 2020 at 11:17:55PM +1000, Aleksa Sarai wrote:
> On 2020-07-15, Kees Cook <[email protected]> wrote:
> > 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.
Yeah, I don't see any sane way to attach ptrace, especially when what's
wanted is just "io_uring action logging", which is a much more narrow
issue, and one that doesn't map well to processes.
Can the io_uring eventfd be used for this kind of thing? It seems
io_uring just needs a way to gain an administrative path to opening it?
> > 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...).
Looking at the per-OP "syscall" implementations, I'm kind of alarmed
that some (e.g. openat2) are rather "open coded". It seems like this
should be fixed to have at least a common entry point for both io_uring
and proper syscalls.
--
Kees Cook
next prev parent reply other threads:[~2020-07-16 15:19 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
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 [this message]
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=202007160812.A8D43ABBBE@keescook \
[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