From: Michael Ellerman <mpe@ellerman.id.au>
To: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Robert O'Callahan <rocallahan@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"maintainer\:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
<x86@kernel.org>,
linux-arch@vger.kernel.org, Will Deacon <will@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Mark Rutland <mark.rutland@arm.com>,
Keno Fischer <keno@juliacomputing.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm list <kvm@vger.kernel.org>,
Gabriel Krisman Bertazi <krisman@collabora.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Kyle Huey <me@kylehuey.com>
Subject: Re: [REGRESSION] x86/entry: Tracer no longer has opportunity to change the syscall number at entry via orig_ax
Date: Sun, 13 Sep 2020 17:44:09 +1000 [thread overview]
Message-ID: <87d02qqfxy.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <202009111609.61E7875B3@keescook>
Kees Cook <keescook@chromium.org> writes:
> On Wed, Sep 09, 2020 at 11:53:42PM +1000, Michael Ellerman wrote:
>> I can observe the difference between v5.8 and mainline, using the
>> raw_syscall trace event and running the seccomp_bpf selftest which turns
>> a getpid (39) into a getppid (110).
>>
>> With v5.8 we see getppid on entry and exit:
>>
>> seccomp_bpf-1307 [000] .... 22974.874393: sys_enter: NR 110 (7ffff22c46e0, 40a350, 4, fffffffffffff7ab, 7fa6ee0d4010, 0)
>> seccomp_bpf-1307 [000] .N.. 22974.874401: sys_exit: NR 110 = 1304
>>
>> Whereas on mainline we see an enter for getpid and an exit for getppid:
>>
>> seccomp_bpf-1030 [000] .... 21.806766: sys_enter: NR 39 (7ffe2f6d1ad0, 40a350, 7ffe2f6d1ad0, 0, 0, 407299)
>> seccomp_bpf-1030 [000] .... 21.806767: sys_exit: NR 110 = 1027
>
> For my own notes, this is how I reproduced it:
>
> # ./perf-$VER record -e raw_syscalls:sys_enter -e raw_syscalls:sys_exit &
> # ./seccomp_bpf
> # fg
> ctrl-c
> # ./perf-$VER script | grep seccomp_bpf | awk '{print $7}' | sort | uniq -c > $VER.log
> *repeat*
> # diff -u old.log new.log
> ...
>
> (Is there an easier way to get those results?)
I did more or less the same thing, except I ran the trace event manually
(via debugfs), which is no better really.
I think the right way to test it would be to have a test that modifies
the syscall via seccomp and also monitors the trace event using perf
events. But that wouldn't be easier :)
> I will go see if I can figure out the best way to correct this.
I think this works?
diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index 18683598edbc..901361e2f8ea 100644
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -60,13 +60,15 @@ static long syscall_trace_enter(struct pt_regs *regs, long syscall,
return ret;
}
+ syscall = syscall_get_nr(current, regs);
+
if (unlikely(ti_work & _TIF_SYSCALL_TRACEPOINT))
trace_sys_enter(regs, syscall);
syscall_enter_audit(regs, syscall);
/* The above might have changed the syscall number */
- return ret ? : syscall_get_nr(current, regs);
+ return ret ? : syscall;
}
static __always_inline long
cheers
next prev parent reply other threads:[~2020-09-13 7:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 17:14 [REGRESSION] x86/entry: Tracer no longer has opportunity to change the syscall number at entry via orig_ax Kyle Huey
2020-08-19 19:44 ` Thomas Gleixner
2020-08-20 17:26 ` Kyle Huey
2020-08-20 21:09 ` Kees Cook
2020-08-21 0:35 ` Thomas Gleixner
2020-08-21 14:21 ` [tip: core/urgent] core/entry: Respect syscall number rewrites tip-bot2 for Thomas Gleixner
[not found] ` <87a6xzrr89.fsf@mpe.ellerman.id.au>
2020-09-11 18:58 ` [REGRESSION] x86/entry: Tracer no longer has opportunity to change the syscall number at entry via orig_ax Kees Cook
2020-09-12 0:10 ` Kees Cook
2020-09-13 7:44 ` Michael Ellerman [this message]
2020-09-13 18:27 ` Thomas Gleixner
2020-09-14 20:04 ` Kees Cook
2020-09-17 0:39 ` Michael Ellerman
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=87d02qqfxy.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=arnd@arndb.de \
--cc=keescook@chromium.org \
--cc=keno@juliacomputing.com \
--cc=krisman@collabora.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=me@kylehuey.com \
--cc=pbonzini@redhat.com \
--cc=rocallahan@gmail.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.