linux-kernel - Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL

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: <20181108091638.GA9939@redhat.com>
Date:   Thu, 8 Nov 2018 10:16:38 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Elvira Khabirova <lineprinter@...linux.org>
Cc:     Andy Lutomirski <luto@...capital.net>, rostedt@...dmis.org,
        mingo@...hat.com, linux-kernel@...r.kernel.org, ldv@...linux.org,
        esyr@...hat.com, luto@...nel.org, strace-devel@...ts.strace.io
Subject: Re: [RFC PATCH] ptrace: add PTRACE_GET_SYSCALL_INFO request

On 11/07, Elvira Khabirova wrote:
>
> On Wed, 7 Nov 2018 17:44:44 +0100
> Oleg Nesterov <oleg@...hat.com> wrote:
>
> > To me PT_IN_SYSCALL_STOP makes no real sense, but I won't argue.
> >
> > At least I'd ask to not abuse task->ptrace. ptrace_report_syscall() can clear
> > ->ptrace_message on exit if we really want PTRACE_GET_SYSCALL_INFO to fail after
> > that.
>
> I really would not like to rely on ->ptrace_message remaining empty;
> this looks too fragile.

Well. I do not understand why this is fragile. And certainly this is not more
fragile than

	current->ptrace |= PT_IN_SYSCALL_STOP;
	trace_notify();
	current->ptrace &= ~PT_IN_SYSCALL_STOP;

simply because both ->ptrace updates are technically wrong. The tracee can race
with the exiting tracer which clears ->ptrace.

But even if this was correct. This patch manipulates ->ptrace_message anyway,
I do not understand why should we abuse ->ptrace too just to for the sanity
check in PTRACE_GET_SYSCALL_INFO.

Oleg.