From: "Mickaël Salaün" <mic@digikod.net>
To: Richard Weinberger <richard@nod.at>, linux-kernel@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>, Jeff Dike <jdike@addtoit.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>,
Shuah Khan <shuahkh@osg.samsung.com>,
Chris Metcalf <cmetcalf@ezchip.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Andrew Morton <akpm@linux-foundation.org>,
James Hogan <james.hogan@imgtec.com>,
Thomas Meyer <thomas@m3y3r.de>,
Nicolas Iooss <nicolas.iooss_linux@m4x.org>,
Anton Ivanov <aivanov@brocade.com>,
linux-doc@vger.kernel.org,
user-mode-linux-devel@lists.sourceforge.net,
user-mode-linux-user@lists.sourceforge.net,
linux-api@vger.kernel.org,
Meredydd Luff <meredydd@senatehouse.org>,
David Drysdale <drysdale@google.com>
Subject: Re: [PATCH v1 1/4] um: Fix ptrace GETREGS/SETREGS bugs
Date: Mon, 21 Dec 2015 20:10:54 +0100 [thread overview]
Message-ID: <56784EBE.7050403@digikod.net> (raw)
In-Reply-To: <5677D0CD.1070602@nod.at>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On 21/12/2015 11:13, Richard Weinberger wrote:
> Am 21.12.2015 um 10:23 schrieb Mickaël Salaün:
>>>>> Doesn't this break the support for changing syscall numbers using PTRACE_SETREGS?
>>>>
>>>> The logic is unchanged except updating the UPT_SYSCALL_NR before syscall_trace_enter(). I did my last tests with the x86_32 subarchitecture and all tests (from selftest/seccomp), including PTRACE_SETREGS for syscall numbers tests, passed. However, 2 of this tests still fail for x86_64 (only).
>>>
>>> No, the logic is different.
>>> syscall_trace_enter(regs) enters the ptrace() path and here registers can be changed.
>>> Hence "syscall = UPT_SYSCALL_NR(r);" will see the old syscall number.
>>> UPT_SYSCALL_NR() returns the syscall number before the ptrace() path...
>>
>> The thing is, PTRACE_SETREGS give access to *orig_ax* in the user_regs_struct from arch/x86/include/asm/user_*.h and selftest/seccomp only update this (virtual) register, not the EAX/RAX. Am I missing something?
>
> Sorry, meant orig...
>
> Please see the attached program. It proves that your patch is breaking stuff.
> The test is extracted from UML's selftests.
OK, I found the origin of this misunderstanding. On x86_32, PTRACE_SETREGS set regs->syscall when updating orig_eax, which is not the case on x86_64, hence the difference of behavior. I fixed this bug in the v2 series. The ptsc test and all the seccomp tests pass for 32 and 64 bits!
Where can we find the UML selftests?
Thanks,
Mickaël
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2015-12-21 19:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 0:03 [PATCH v1 0/4] um: Add seccomp support Mickaël Salaün
2015-12-21 0:03 ` [PATCH v1 1/4] um: Fix ptrace GETREGS/SETREGS bugs Mickaël Salaün
[not found] ` <1450656209-2676-2-git-send-email-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
2015-12-21 0:20 ` Richard Weinberger
2015-12-21 8:49 ` Mickaël Salaün
2015-12-21 8:56 ` Richard Weinberger
[not found] ` <5677BD23.4060602-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
2015-12-21 9:00 ` Richard Weinberger
[not found] ` <5677BFBD.3090200-/L3Ra7n9ekc@public.gmane.org>
2015-12-21 9:23 ` Mickaël Salaün
2015-12-21 10:13 ` Richard Weinberger
2015-12-21 19:10 ` Mickaël Salaün [this message]
[not found] ` <1450656209-2676-1-git-send-email-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
2015-12-21 0:03 ` [PATCH v1 2/4] selftests/seccomp: Remove the need for HAVE_ARCH_TRACEHOOK Mickaël Salaün
2015-12-21 0:03 ` [PATCH v1 4/4] um: Add seccomp support Mickaël Salaün
2015-12-21 0:03 ` [PATCH v1 3/4] um: Add full asm/syscall.h support Mickaël Salaün
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=56784EBE.7050403@digikod.net \
--to=mic@digikod.net \
--cc=aivanov@brocade.com \
--cc=akpm@linux-foundation.org \
--cc=cmetcalf@ezchip.com \
--cc=corbet@lwn.net \
--cc=drysdale@google.com \
--cc=hpa@zytor.com \
--cc=james.hogan@imgtec.com \
--cc=jdike@addtoit.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=meredydd@senatehouse.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=nicolas.iooss_linux@m4x.org \
--cc=richard@nod.at \
--cc=shuahkh@osg.samsung.com \
--cc=tglx@linutronix.de \
--cc=thomas@m3y3r.de \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=user-mode-linux-user@lists.sourceforge.net \
--cc=wad@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).