From: Al Viro <viro@zeniv.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
David Laight <David.Laight@aculab.com>,
Christoph Hellwig <hch@lst.de>,
linux-kernel@vger.kernel.org, X86 ML <x86@kernel.org>
Subject: Re: in_compat_syscall() on x86
Date: Tue, 5 Jan 2021 00:57:00 +0000 [thread overview]
Message-ID: <20210105005700.GR3579531@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87mtxodxat.fsf@x220.int.ebiederm.org>
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...
next prev parent reply other threads:[~2021-01-05 0:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 12:16 in_compat_syscall() on x86 David Laight
2021-01-04 16:46 ` David Laight
2021-01-04 16:58 ` Al Viro
2021-01-04 20:41 ` Eric W. Biederman
2021-01-04 22:34 ` David Laight
2021-01-04 23:04 ` Andy Lutomirski
2021-01-05 0:47 ` Eric W. Biederman
2021-01-05 0:57 ` Al Viro [this message]
2021-01-06 0:03 ` Eric W. Biederman
2021-01-06 0:11 ` Bernd Petrovitsch
2021-01-06 0:30 ` Al Viro
2021-01-05 9:53 ` David Laight
2021-01-05 17:35 ` Andy Lutomirski
2021-01-06 9:42 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210105005700.GR3579531@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=David.Laight@aculab.com \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.