linux-kernel - Re: PTRACE_SYSEMU behavior difference on arm64

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: <20200515121346.GA22919@willie-the-truck>
Date:   Fri, 15 May 2020 13:13:47 +0100
From:   Will Deacon <will@...nel.org>
To:     Keno Fischer <keno@...iacomputing.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: PTRACE_SYSEMU behavior difference on arm64

Hi Keno,

On Fri, May 15, 2020 at 07:15:35AM -0400, Keno Fischer wrote:
> The behavior of PTRACE_SYSEMU on arm64
> appears to differ substantially from that of x86 and powerpc
> (the other two architectures on which this feature is implemented).
> In particular, after PTRACE_SYSEMU the syscall will always
> be skipped on x86 and powerpc, but executed on arm64 unless
> the syscall-entry stop was again continued using PTRACE_SYSEMU.
> The skipping behavior is also documented in the manpage,
> so I suspect this may just be a bug (the skipping behavior
> makes sense to me and is what I would expect).
> The reason this happens is that `syscall_trace_enter`
> re-checks TIF_SYSCALL_EMU after the ptrace stop, but at that
> point it may have already been superseded by a new ptrace
> request. x86 and power save the original value of the flag,
> rather than acting on the new value. I can submit a patch to
> fix this, but wanted to check first whether this was intentional.
> If it is, I can fix the man page instead.

Please send a patch, since this looks like a silly bug to me. But it also
means that nobody is using this on arm64, so we could also consider removing
it entirely. Did you spot this because you are trying to use it for
something or just by inspection/unit-testing?

Will