linux-kernel - Re: [PATCH 1/2] alpha/ptrace: Record and handle the absence of switch

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 for Android: free password hash cracker in your pocket

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

Message-ID: <YNALIY2vhvzKi+Sy@zeniv-ca.linux.org.uk>
Date:   Mon, 21 Jun 2021 03:44:33 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Michael Schmitz <schmitzmic@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>, Oleg Nesterov <oleg@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        alpha <linux-alpha@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Arnd Bergmann <arnd@...nel.org>,
        Ley Foon Tan <ley.foon.tan@...el.com>,
        Tejun Heo <tj@...nel.org>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 1/2] alpha/ptrace: Record and handle the absence of
 switch_stack

On Mon, Jun 21, 2021 at 03:18:35PM +1200, Michael Schmitz wrote:

> This is what I get from WARN_ONCE:
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1177 at arch/m68k/kernel/ptrace.c:91 get_reg+0x90/0xb8
> Modules linked in:
> CPU: 0 PID: 1177 Comm: strace Not tainted 5.13.0-rc1-atari-fpuemu-exitfix+
> #1146
> Stack from 014b7f04:
>         014b7f04 00336401 00336401 000278f0 0032c015 0000005b 00000005
> 0002795a
>         0032c015 0000005b 0000338c 00000009 00000000 00000000 ffffffe4
> 00000005
>         00000003 00000014 00000003 00000014 efc2b90c 0000338c 0032c015
> 0000005b
>         00000009 00000000 efc2b908 00912540 efc2b908 000034cc 00912540
> 00000005
>         00000000 efc2b908 00000003 00912540 8000110c c010b0a4 efc2b90c
> 0002d1d8
>         00912540 00000003 00000014 efc2b908 0000049a 00000014 efc2b908
> 800acaa8
> Call Trace: [<000278f0>] __warn+0x9e/0xb4
>  [<0002795a>] warn_slowpath_fmt+0x54/0x62
>  [<0000338c>] get_reg+0x90/0xb8
>  [<0000338c>] get_reg+0x90/0xb8
>  [<000034cc>] arch_ptrace+0x7e/0x250
>  [<0002d1d8>] sys_ptrace+0x232/0x2f8
>  [<00002ab6>] syscall+0x8/0xc
>  [<0000c00b>] lower+0x7/0x20
> 
> ---[ end trace ee4be53b94695793 ]---
> 
> Syscall numbers are actually 90 and 192 - sys_old_mmap and sys_mmap2 on
> m68k. Used the calculator on my Ubuntu desktop, that appears to be a little
> confused about hex to decimal conversions.
> 
> I hope that makes more sense?

Not really; what is the condition you are checking?  The interesting trace
is not that with get_reg() - it's that of the process being traced.  You
are not accessing the stack of caller of ptrace(2) here, so you want to
know that SAVE_SWITCH_STACK had been done by the tracee, not tracer.

And if that had been strace ls, you have TIF_SYSCALL_TRACE set for ls, so
	* ls hits system_call
	* notices TIF_SYSCALL_TRACE and goes to do_trace_entry
	* does SAVE_SWITCH_STACK there
	* calls syscall_trace(), which calls ptrace_notify()
	* ptrace_notify() calls ptrace_do_notify(), which calls ptrace_stop()
	* ptrace_stop() arranges for tracer to be woken up and gives CPU up,
with TASK_TRACED as process state.

That's the callchain in ls, and switch_stack accessed by get_reg() from
strace is the one on ls(1) stack created by SAVE_SWITCH_STACK.