From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBCDBC433E0 for ; Wed, 6 Jan 2021 00:05:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1F1C230FB for ; Wed, 6 Jan 2021 00:05:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726520AbhAFAEz (ORCPT ); Tue, 5 Jan 2021 19:04:55 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:37490 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbhAFAEy (ORCPT ); Tue, 5 Jan 2021 19:04:54 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kwwJ9-0096Vf-V8; Tue, 05 Jan 2021 17:04:11 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kwwJ8-00F3C8-UK; Tue, 05 Jan 2021 17:04:11 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Al Viro Cc: Andy Lutomirski , David Laight , Christoph Hellwig , linux-kernel@vger.kernel.org, X86 ML References: <091174F9-F6E4-468E-83F5-93706D83F9D2@amacapital.net> <87mtxodxat.fsf@x220.int.ebiederm.org> <20210105005700.GR3579531@ZenIV.linux.org.uk> Date: Tue, 05 Jan 2021 18:03:15 -0600 In-Reply-To: <20210105005700.GR3579531@ZenIV.linux.org.uk> (Al Viro's message of "Tue, 5 Jan 2021 00:57:00 +0000") Message-ID: <878s97aq4c.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 X-XM-SPF: eid=1kwwJ8-00F3C8-UK;;;mid=<878s97aq4c.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX180UoD4z9fnJNpVE49//IpmnCZhCUm1qQk= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: in_compat_syscall() on x86 X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Al Viro writes: > 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? Any code that no one uses is better off disabled or deleted. There are maintenance and support costs to such code as they cause extra work when maintaining the kernel, and because the code is practically never tested inevitably bugs some of which turn into security issues slip through. Maybe I am wrong and there are interesting users of x32. All I remember is that last time this was discussed someone found a distro that actually shipped an x32 build to users. Which was just enough users to keep x32 alive. Given that distros are in the process of dropping 32bit support I suspect that distro may be going if it is not already gone. There are a lot of weird x32 special cases that it would be nice to get rid of if no one uses x32, and could certainly be made less of an issue if distro's that don't actually care about x32 simply stopped compiling it in. >> 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. That does sound interesting. Anytime we can clean up arch specific weirdness so that it simply becomes generic weirdness and it can be tested and maintained by more people is always nice. > I really don't see the point of getting rid of x32 - mips n32 is *not* > going away, and that's an exact parallel. >From what I maintain x32 and n32 are *not* exact parallels. The change in size of the timestamps of SIGCHLD is not present on any other architecture. The truth is someone years ago royallying messed up struct siginfo and took a structure that should have been the same on 32bit and 64bit and would up with a horrible monstrosity of unions. > 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... It sounds like we are already on our way to having that. I suspect you would need an binfmt_elf_ops to handle the architecture specific bits, but it should not be too bad. Eric