Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Eric W. Biederman" <ebiederm@xmission.com>
To:     Kees Cook <keescook@chromium.org>
Cc:     John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
        Borislav Petkov <bp@alien8.de>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Theodore Ts'o <tytso@mit.edu>, X86 ML <x86@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Matt Turner <mattst88@gmail.com>,
        =?utf-8?Q?M=C3=A5ns_Rullg=C3=A5rd?= <mans@mansr.com>,
        Michael Cree <mcree@orcon.net.nz>,
        <linux-arch@vger.kernel.org>, Richard Henderson <rth@twiddle.net>,
        Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        linux-m68k@lists.linux-m68k.org,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <20220113160115.5375-1-bp@alien8.de> <YeBzxuO0wLn/B2Ew@mit.edu>
        <YeCuNapJLK4M5sat@zn.tnic>
        <CAMuHMdUbTNNr16YY1TFe=-uRLjg6yGzgw_RqtAFpyhnOMM5Pvw@mail.gmail.com>
        <YeHLIDsjGB944GSP@zn.tnic>
        <CAMuHMdUBr+gpF6Z5nPadjHFYJwgGd+LGoNTV=Sxty+yaY5EWxg@mail.gmail.com>
        <YeHQmbMYyy92AbBp@zn.tnic> <YeKyBP5rac8sVvWw@zn.tnic>
        <b40d1377-51d5-4ba3-ab3f-b40626c229ad@physik.fu-berlin.de>
Date:   Wed, 09 Mar 2022 14:03:42 -0600
In-Reply-To: <b40d1377-51d5-4ba3-ab3f-b40626c229ad@physik.fu-berlin.de> (John
        Paul Adrian Glaubitz's message of "Sat, 15 Jan 2022 20:42:59 +0100")
Message-ID: <87ilsmdhb5.fsf_-_@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: [PATCH] a.out: Stop building a.out/osf1 support on alpha and m68k
Precedence: bulk


There has been repeated discussion on removing a.out support, the most
recent was[1].  Having read through a bunch of the discussion it looks
like no one has see any reason why we need to keep a.out support.

The m68k maintainer has even come out in favor of removing a.out
support[2].

At a practical level with only two rarely used architectures building
a.out support, it gets increasingly hard to test and to care about.
Which means the code will almost certainly bit-rot.

Let's see if anyone cares about a.out support on the last two
architectures that build it, by disabling the build of the support in
Kconfig.  If anyone cares, this can be easily reverted, and we can then
have a discussion about what it is going to take to support a.out
binaries in the long term.

Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: linux-alpha@vger.kernel.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
[1] https://lkml.kernel.org/r/20220113160115.5375-1-bp@alien8.de
[2] https://lkml.kernel.org/r/CAMuHMdUbTNNr16YY1TFe=-uRLjg6yGzgw_RqtAFpyhnOMM5Pvw@mail.gmail.com
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---

Kees do you think you could add this to your execve branch?

I think this should be a complimentary patch to Borislav Petkov's patch
at the top of this tread to remove a.out support on x86.

 arch/alpha/Kconfig | 1 -
 arch/m68k/Kconfig  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 4e87783c90ad..14c97acea351 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -12,7 +12,6 @@ config ALPHA
 	select FORCE_PCI if !ALPHA_JENSEN
 	select PCI_DOMAINS if PCI
 	select PCI_SYSCALL if PCI
-	select HAVE_AOUT
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_PCSPKR_PLATFORM
 	select HAVE_PERF_EVENTS
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 936e1803c7c7..268b3860d40d 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -17,7 +17,6 @@ config M68K
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_SHOW
-	select HAVE_AOUT if MMU
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_HAS_NO_UNALIGNED
-- 
2.29.2