linux-kernel - Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181129144742.GB10645@redhat.com>
Date:   Thu, 29 Nov 2018 15:47:43 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     "Dmitry V. Levin" <ldv@...linux.org>
Cc:     Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Elvira Khabirova <lineprinter@...linux.org>,
        Eugene Syromyatnikov <esyr@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        linux-api@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        strace-devel@...ts.strace.io
Subject: Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in
 ptrace_message

On 11/29, Dmitry V. Levin wrote:
>
> 2. Document these values

sure, they should be documented and live in include/uapi/,

> chosen to avoid collisions with ptrace_message values
> set by other ptrace events

this is what I can't understand. But to clarify, I don't really care and
won't argue.

If an application wants to use PTRACE_GETEVENTMSG to distinguish entry/exit
(without PTRACE_GET_SYSCALL_INFO) it needs to do wait(status) and check status
anyway, otherwise PTRACE_GETEVENTMSG is simply pointless (wrt syscall entry/
exit). So we do not care if PTRACE_EVENTMSG_SYSCALL_ENTRY conflicts with, say,
SECCOMP_RET_DATA.

> so that PTRACE_GETEVENTMSG users can easily tell
> whether this new semantics is supported by the kernel or not.

Yes. And how much this can help? Again, an application can trivially detect
if this feature implemented or not, and it should do this anyway if it wants
to (try to) use PTRACE_EVENTMSG_SYSCALL_ENTRY/EXIT ?

Again, I won't reallly argue. But if you insist that these values must be
unique then you probably need to add

	BUILD_BUG_ON(PTRACE_EVENTMSG_SYSCALL_ENTRY <= PID_MAX_LIMIT);

?

OK, please forget...

Oleg.