Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 04 Jan 2021 14:41:01 -0600 | Subject | Re: in_compat_syscall() on x86 |
| |
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
| |