Re: in_compat_syscall() on x86

[Al Viro]

On Mon, Jan 04, 2021 at 06:47:38PM -0600, Eric W. Biederman wrote:
> >> It is defined in the Ubuntu kernel configs I've got lurking:
> >> Both 3.8.0-19_generic (Ubuntu 13.04) and 5.4.0-56_generic (probably 20.04).
> >> Which is probably why it is in my test builds (I've just cut out
> >> a lot of modules).
> 
> Interesting.  That sounds like something a gentle prod to the Ubuntu
> kernel team might get them to disable.  Especially if there are not any
> x32 binaries in sight.

What for?

> The core dump code is currently tied to what binary you exec.
> The code in exec sets mm->binfmt, and the coredump code uses mm->binfmt
> to pick the coredump handler.
> 
> An x32 binary will make all kinds of 64bit calls where it doesn't need
> the compat handling.  And of course x32 binaries run in 64bit mode with
> 32bit pointers so looking at the current execution mode doesn't help.
> 
> Further fun compat_binfmt_elf is shared between x32 and ia32, because
> except for a few stray places they do exactly the same thing.

FWIW, there's a series cleaning that crap up nicely; as a side benefit,
it converts both compats on mips (o32 and n32) to regular compat_binfmt_elf.c
Yes, the current mainline is bloody awful in that area (PRSTATUS_SIZE and
SET_PR_FPVALID are not for weak stomach), but that's really not hard to
get into sane shape - -next had that done in last cycle and I'm currently
testing (well, building the test kernel) of port of that to 5.11-rc1.

I really don't see the point of getting rid of x32 - mips n32 is *not*
going away, and that's an exact parallel.

PS: if anything, I wonder if we would better off with binfmt_elf{64,32}.o,
built from fs/binfmt_elf.c; it's not that hard to do.  With arseloads
of weirdness going away if we do that...