MIME-Version: 1.0
In-Reply-To: <CA+55aFx6Ade9UwDQ2KgsQgVMog+B9VXNYqrb1vm+EvBbkazhuA@mail.gmail.com>
References: <CAHse=S8UeYVJqRBx-_wf=jeDERTJxzM=YRH5izBpQnrCHOxcDA@mail.gmail.com>
 <55CCB510.3060807@redhat.com> <CAHse=S8BrL6KeQL9gwa=9TH0nqWrNxq7rcHc--pAVriG+pxBmA@mail.gmail.com>
 <CALCETrXP0bH9nhh=aOPsiA-Bs0zNW_0xbXFhvbMPZeDV71VtZA@mail.gmail.com>
 <CAHse=S8OuPb4KFWBXJS6c9YdGPEH8MgpbWJ5qP79r04+4rK2Fw@mail.gmail.com>
 <CAGXu5j+gXShOAdK93KuVide93VYA_ObyjbK-zb7CwgOLc2JCnQ@mail.gmail.com>
 <55CD0DAC.9080809@redhat.com> <CALCETrWj6X+zCX47iHip0Qjp88p7f3p0uWvskL357XCyvPrXVA@mail.gmail.com>
 <CA+55aFyA9+16Jer2nKMOs6_uhRA-egvFDSR8fgNoD9AuPLE4GQ@mail.gmail.com> <CA+55aFx6Ade9UwDQ2KgsQgVMog+B9VXNYqrb1vm+EvBbkazhuA@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Thu, 13 Aug 2015 15:58:50 -0700
Message-ID: <CALCETrUCXkKvD2K+U2WcGg6-7aJgqJuc99NbUzH9egAFx7Supw@mail.gmail.com>
Subject: Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values
 wrong in VM?
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>, Kees Cook <keescook@chromium.org>,
        David Drysdale <drysdale@google.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Will Drewry <wad@chromium.org>, Ingo Molnar <mingo@kernel.org>,
        Alok Kataria <akataria@vmware.com>, Borislav Petkov <bp@alien8.de>,
        Alexei Starovoitov <ast@plumgrid.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Oleg Nesterov <oleg@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>, X86 ML <x86@kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1923
Lines: 52

On Thu, Aug 13, 2015 at 3:54 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Aug 13, 2015 at 3:49 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Does the attached patch make sense and work?
>
> Btw, I'm not all that happy with it anyway.
>
> I still think Denys' patch also potentially changed what audit and
> strace see for %rax in the pt_regs to -ENOSYS, which I'm not convinced
> is a good change.

For better for for worse, the native 64-bit path changed several
versions agi, and nothing broke that I'm aware of.  The change was:

commit 54eea9957f5763dd1a2555d7e4cb53b4dd389cc6
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Fri Sep 5 15:13:55 2014 -0700

    x86_64, entry: Treat regs->ax the same in fastpath and slowpath syscalls

AFAIK, ptrace has always seen ax == -ENOSYS on syscall entry for
native 64-bit syscalls.  My change just simplified the fast path
(which is invisible by ptrace for obvious reasons, unless someone
traces fork or something along those lines *without*) and made it less
different from the slow path.  (IIRC it also simplified some stuff
down the road.)

Looking at 3.19's ia32entry.S, it has:

sysenter_tracesys:
#ifdef CONFIG_AUDITSYSCALL
        testl   $(_TIF_WORK_SYSCALL_ENTRY &
~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET)
        jz      sysenter_auditsys
#endif
        SAVE_REST
        CLEAR_RREGS
        movq    $-ENOSYS,RAX(%rsp)/* ptrace can change this for a bad syscall */

So I think it's always been the intent and practice that ptracers
would see ax == -ENOSYS on syscall entry.

IOW, whether this is good or bad, I don't think it's really a change.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/