Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     David Laight <David.Laight@aculab.com>,
        Christoph Hellwig <hch@lst.de>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        X86 ML <x86@kernel.org>
References: <e817cfdc2df3433bb7fb357db89d4d48@AcuMS.aculab.com>
        <20210104165827.GJ3579531@ZenIV.linux.org.uk>
Date:   Mon, 04 Jan 2021 14:41:01 -0600
In-Reply-To: <20210104165827.GJ3579531@ZenIV.linux.org.uk> (Al Viro's message
        of "Mon, 4 Jan 2021 16:58:27 +0000")
Message-ID: <87sg7gfnaa.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: in_compat_syscall() on x86
Precedence: bulk

Al Viro <viro@zeniv.linux.org.uk> writes:

> On Mon, Jan 04, 2021 at 12:16:56PM +0000, David Laight wrote:
>> On x86 in_compat_syscall() is defined as:
>>     in_ia32_syscall() || in_x32_syscall()
>> 
>> Now in_ia32_syscall() is a simple check of the TS_COMPAT flag.
>> However in_x32_syscall() is a horrid beast that has to indirect
>> through to the original %eax value (ie the syscall number) and
>> check for a bit there.
>> 
>> So on a kernel with x32 support (probably most distro kernels)
>> the in_compat_syscall() check is rather more expensive than
>> one might expect.

I suggest you check the distro kernels.  I suspect they don't compile in
support for x32.  As far as I can tell x32 is an undead beast of a
subarchitecture that just enough people use that it can't be removed,
but few enough people use it likely has a few lurking scary bugs.

>> It would be muck better if both checks could be done together.
>> I think this would require the syscall entry code to set a
>> value in both the 64bit and x32 entry paths.
>> (Can a process make both 64bit and x32 system calls?)
>
> Yes, it bloody well can.
>
> And I see no benefit in pushing that logics into syscall entry,
> since anything that calls in_compat_syscall() more than once
> per syscall execution is doing the wrong thing.  Moreover,
> in quite a few cases we don't call the sucker at all, and for
> all of those pushing that crap into syscall entry logics is
> pure loss.

The x32 system calls have their own system call table and it would be
trivial to set a flag like TS_COMPAT when looking up a system call from
that table.  I expect such a change would be purely in the noise.

> What's the point, really?

Before we came up with the current games with __copy_siginfo_to_user
and x32_copy_siginfo_to_user I was wondering if we should make such
a change.  The delivery of compat signal frames and core dumps which
do not go through the system call entry path could almost benefit from
a flag that could be set/tested when on those paths.

The fact that only SIGCHLD (which can not trigger a coredump) is
different saves the coredump code from needing such a test.

The fact that the signal frame code is simple enough it can directly
call x32_copy_siginfo_to_user or __copy_siginfo_to_user saves us there.

So I don't think we have any cases where we actually need a flag that
is independent of the system call but we have come very close.


For people who want to optimize I suggest tracking down the handful of
users of x32 and see if x32 can be made to just go away.

Eric