From: Andy Lutomirski <luto@kernel.org>
To: Elvira Khabirova <lineprinter@altlinux.org>,
Kees Cook <keescook@chromium.org>,
Sasha Levin <sasha.levin@oracle.com>,
Linux API <linux-api@vger.kernel.org>,
Jann Horn <jannh@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
"Dmitry V. Levin" <ldv@altlinux.org>,
Eugene Syromiatnikov <esyr@redhat.com>,
Andrew Lutomirski <luto@kernel.org>,
strace-devel@lists.strace.io
Subject: Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request
Date: Wed, 21 Nov 2018 14:56:57 -0800 [thread overview]
Message-ID: <CALCETrV3TPCkYyhoLLcikXVeF-RdZUuLTCvKReK3Qb9LSS9Csw@mail.gmail.com> (raw)
In-Reply-To: <20181121165806.07da7c98@akathisia>
Please cc linux-api@vger.kernel.org for future versions.
On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova
<lineprinter@altlinux.org> wrote:
>
> struct ptrace_syscall_info {
> __u8 op; /* 0 for entry, 1 for exit */
Can you add proper defines, like:
#define PTRACE_SYSCALL_ENTRY 0
#define PTRACE_SYSCALL_EXIT 1
#define PTRACE_SYSCALL_SECCOMP 2
and make seccomp work from the start? I'd rather we don't merge an
implementation that doesn't work for seccomp and then have to rework
it later.
> __u8 __pad0[7];
> union {
> struct {
> __s32 nr;
__u64 please. Syscall numbers are, as a practical matter, 64 bits.
Admittedly, the actual effects of setting the high bits are unclear,
and seccomp has issues with it, but let's not perpetuate the problem.
> __u32 arch;
> __u64 instruction_pointer;
> __u64 args[6];
> } entry_info;
> struct {
> __s64 rval;
> __u8 is_error;
> __u8 __pad1[7];
> } exit_info;
> };
> };
Should seccomp events use entry_info or should they just literally
supply seccomp_data?
next prev parent reply other threads:[~2018-11-21 22:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 15:58 Elvira Khabirova
2018-11-21 22:56 ` Andy Lutomirski [this message]
2018-11-21 23:56 ` Dmitry V. Levin
2018-11-22 14:55 ` Andy Lutomirski
2018-11-22 19:15 ` Dmitry V. Levin
2018-11-23 0:19 ` Andy Lutomirski
2018-11-23 4:01 ` Dmitry V. Levin
2018-11-25 4:10 ` Dmitry V. Levin
2018-11-27 22:28 ` Kees Cook
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=CALCETrV3TPCkYyhoLLcikXVeF-RdZUuLTCvKReK3Qb9LSS9Csw@mail.gmail.com \
--to=luto@kernel.org \
--cc=esyr@redhat.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=ldv@altlinux.org \
--cc=lineprinter@altlinux.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sasha.levin@oracle.com \
--cc=strace-devel@lists.strace.io \
/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
all inboxes | Powered by JetHome®