linux-kernel - Re: in_compat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Jan 2021 00:57:00 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        David Laight <David.Laight@...lab.com>,
        Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
        X86 ML <x86@...nel.org>
Subject: Re: in_compat_syscall() on x86

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...