linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* a.out coredumping: fix or delete?
@ 2019-03-01 23:57 Jann Horn
  2019-03-03  1:09 ` Andy Lutomirski
  2019-03-05  9:19 ` Borislav Petkov
  0 siblings, 2 replies; 42+ messages in thread
From: Jann Horn @ 2019-03-01 23:57 UTC (permalink / raw)
  To: Al Viro
  Cc: Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API

In theory, Linux can dump cores for a.out binaries. In practice, that
code is pretty bitrotten and buggy. Does anyone want that code so much
that they'd like to fix it, or can we just delete it?

Here's a shell script that will give you a minimal a.out binary that
Linux will execute (and that then segfaults immediately because it has
no executable pages mapped):

==============
#!/bin/bash
(
  # a_info: magic=OMAGIC
  printf '\x07\x01'
  # a_info: machtype=M_386
  printf '\x64'
  # a_info: flags=0
  printf '\x00'

  # a_text, a_data, a_bss, a_syms: 0
  printf '\x00\x00\x00\x00'
  printf '\x00\x00\x00\x00'
  printf '\x00\x00\x00\x00'
  printf '\x00\x00\x00\x00'

  # a_entry: 0x42424242
  printf '\x42\x42\x42\x42'

  # a_trsize, a_drsize: 0
  printf '\x00\x00\x00\x00'
  printf '\x00\x00\x00\x00'
) > aout_binary
chmod +x aout_binary
==============

You need a kernel with CONFIG_IA32_AOUT enabled (for x86-64) or with
CONFIG_BINFMT_AOUT enabled (for 32-bit x86). If aout is built as a
module, you have to manually load it with "modprobe binfmt_aout",
because even though there is binfmt autoloading code in the kernel, no
aliases are set up for any binfmts.

On a Debian 9 system with a 4.9 stable kernel, if you try to run this
a.out program with core dumps enabled ("ulimit -c unlimited") a few
times, the kernel oopses:

==============
[ 2659.912016] aout_binary[978]: segfault at 42424242 ip 42424242 sp
bfffe4e0 error 14
[ 2659.912318] BUG: unable to handle kernel paging request at bffff000
[ 2659.912336] IP: [<d030bd14>] memcpy+0x14/0x30
[ 2659.912364] *pdpt = 00000000367f7001 *pde = 000000007d0d1067
[ 2659.912368] Oops: 0000 [#1] SMP
[ 2659.912377] Modules linked in: binfmt_aout [...]
[ 2659.912421] CPU: 0 PID: 978 Comm: aout_binary Not tainted
4.9.0-8-686-pae #1 Debian 4.9.144-3.1
[ 2659.912422] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 2659.912424] task: f30e2000 task.stack: f470a000
[ 2659.912428] EIP: 0060:[<d030bd14>] EFLAGS: 00010206 CPU: 0
[ 2659.912430] EIP is at memcpy+0x14/0x30
[ 2659.912431] EAX: fffba000 EBX: 00001000 ECX: 00000400 EDX: bffff000
[ 2659.912433] ESI: bffff000 EDI: fffba000 EBP: f470bab0 ESP: f470baa4
[ 2659.912434]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 2659.912436] CR0: 80050033 CR2: bffff000 CR3: 346ad4e0 CR4: 001406f0
[ 2659.912442] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 2659.912444] DR6: fffe0ff0 DR7: 00000400
[ 2659.912445] Stack:
[ 2659.912446]  f470bbf0 bffff000 00001000 00001000 d03111a2 f470bb28
00003000 00000000
[ 2659.912449]  fffbb000 f470bc10 fffba000 6721debb 00001000 00002000
00000000 f470bb40
[ 2659.912452]  d016cd10 00001000 00000000 00001000 00000001 f470bb28
f470bb2c 00001000
[ 2659.912456] Call Trace:
[ 2659.912475]  [<d03111a2>] ? iov_iter_copy_from_user_atomic+0x1a2/0x230
[ 2659.912488]  [<d016cd10>] ? generic_perform_write+0xe0/0x1d0
[ 2659.912492]  [<d016ef52>] ? __generic_file_write_iter+0x192/0x1f0
[ 2659.912501]  [<d0217c67>] ? __find_get_block+0xc7/0x250
[ 2659.912512]  [<f8680496>] ? ext4_file_write_iter+0x86/0x460 [ext4]
[ 2659.912514]  [<f85c7050>] ? crc32c_intel_init+0x20/0x20 [crc32c_intel]
[ 2659.912517]  [<d021816c>] ? __getblk_gfp+0x2c/0x310
[ 2659.912523]  [<d01e12bc>] ? generic_file_llseek_size+0x13c/0x1e0
[ 2659.912525]  [<d01e1eac>] ? new_sync_write+0xcc/0x130
[ 2659.912527]  [<d01e1faf>] ? __kernel_write+0x4f/0x100
[ 2659.912537]  [<d023b382>] ? dump_emit+0x92/0xe0
[ 2659.912539]  [<f86fead5>] ? aout_core_dump+0x2a5/0x2f1 [binfmt_aout]
[ 2659.912542]  [<d023bb43>] ? do_coredump+0x4d3/0xde0
[...]
[ 2659.912618] Code: 58 2b 43 50 88 43 4e 5b 5d c3 90 8d 74 26 00 e8
43 fb ff ff eb e8 90 55 89 e5 57 56 53 3e 8d 74 26 00 89 cb 89 c7 c1
e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 5b 5e 5f 5d c3 8d b6 00
00 00
[ 2659.912639] EIP: [<d030bd14>]
[ 2659.912641] memcpy+0x14/0x30
[ 2659.912642]  SS:ESP 0068:f470baa4
[ 2659.912643] CR2: 00000000bffff000
[ 2659.912645] ---[ end trace 6413c918c629c657 ]---
==============

The problem is that since 43a5d548eb594, aout_core_dump() essentially
calls __kernel_write() on a userspace address, which then causes
iov_iter_init() to decide based on uaccess_kernel() that it should use
ITER_KVEC and access the userspace memory with memcpy().


If you try to reproduce this on a 64-bit system with a master branch
kernel, it doesn't work. But that's because that code is even more
broken: The userspace stack pointer is something like 0xffffc4c8, but
fill_dump() for some reason assumes that top-of-stack is at
0xc0000000, causing it to not even attempt to dump the stack:

        if (dump->start_stack < 0xc0000000) {
                unsigned long tmp;

                tmp = (unsigned long) (0xc0000000 - dump->start_stack);
                dump->u_ssize = tmp >> PAGE_SHIFT;
        }

You can reproduce the oops if you use gdb to move the stack pointer
down below 0xc0000000:

==============
user@debian:~/aout$ ulimit -c unlimited
user@debian:~/aout$ gdb ./aout_binary
[...]
(gdb) break *0x42424242
Breakpoint 1 at 0x42424242
(gdb) run
Starting program: /home/user/aout/aout_binary
[...]
(gdb) p/x $sp
$1 = 0xffffcdcc
(gdb) set $sp=0x80000000
(gdb) detach
Detaching from p[   94.987218] aout_binary[1079]: segfault at 42424242
ip 0000000042424242 sp 0000000080000000 error 14
rogram: /home/us[   94.989368] Code: Bad RIP value.
er/aout/aout_binary, process 1079
(gdb) [   94.991341]
==================================================================
[   94.993463] BUG: KASAN: user-memory-access in
iov_iter_copy_from_user_atomic+0x23d/0x530
[   94.995465] Read of size 4096 at addr 0000000080000000 by task
aout_binary/1079
[   94.997069]
[   94.997417] CPU: 4 PID: 1079 Comm: aout_binary Not tainted 5.0.0-rc8 #292
[   94.998942] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[   95.000809] Call Trace:
[   95.001412]  dump_stack+0x71/0xab
[...]
[   95.004628]  kasan_report+0x176/0x192
[...]
[   95.006746]  memcpy+0x1f/0x50
[   95.007433]  iov_iter_copy_from_user_atomic+0x23d/0x530
[...]
[   95.009459]  generic_perform_write+0x1a1/0x2d0
[...]
[   95.013166]  __generic_file_write_iter+0x264/0x2a0
[   95.014242]  ext4_file_write_iter+0x3a4/0x680
[...]
[   95.027234]  __vfs_write+0x294/0x3b0
[...]
[   95.032673]  __kernel_write+0x91/0x190
[   95.033540]  dump_emit+0x131/0x1d0
[...]
[   95.076087] Disabling lock debugging due to kernel taint
[   95.077287] BUG: unable to handle kernel paging request at 0000000080000000
[   95.078812] #PF error: [normal kernel read fault]
[   95.079845] PGD 1e0629067 P4D 1e0629067 PUD 0
[   95.080831] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
[...]
==============

Also, the non-compat version of the coredump code looks like it leaks
some kernel memory into the coredump through "struct user". I don't
think anyone's going to care much, given that it looks like on distro
kernels, you won't usually be able to load a.out binaries...


The rest of a.out is also kind of weird; for example, there is support
for loading text at an unaligned offset (by copying code into an
anonymous mapping), but from a glance, it looks like the resulting
text mapping wouldn't actually be executable? And there is support for
loading files without mmap handler, except that an earlier security
check prevents the use of files without mmap handler, unless you're on
x86-64, where the copied code in ia32_aout.c is used that doesn't have
that security check.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-01 23:57 a.out coredumping: fix or delete? Jann Horn
@ 2019-03-03  1:09 ` Andy Lutomirski
  2019-03-05  9:19 ` Borislav Petkov
  1 sibling, 0 replies; 42+ messages in thread
From: Andy Lutomirski @ 2019-03-03  1:09 UTC (permalink / raw)
  To: Jann Horn
  Cc: Al Viro, Thomas Gleixner, kernel list, Linux FS Devel,
	the arch/x86 maintainers, Linux API

On Fri, Mar 1, 2019 at 3:57 PM Jann Horn <jannh@google.com> wrote:
>
> In theory, Linux can dump cores for a.out binaries. In practice, that
> code is pretty bitrotten and buggy. Does anyone want that code so much
> that they'd like to fix it, or can we just delete it?

I would propose just deleting it.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-01 23:57 a.out coredumping: fix or delete? Jann Horn
  2019-03-03  1:09 ` Andy Lutomirski
@ 2019-03-05  9:19 ` Borislav Petkov
  2019-03-05 12:22   ` Matthew Wilcox
  1 sibling, 1 reply; 42+ messages in thread
From: Borislav Petkov @ 2019-03-05  9:19 UTC (permalink / raw)
  To: Jann Horn
  Cc: Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API

On Sat, Mar 02, 2019 at 12:57:30AM +0100, Jann Horn wrote:
> In theory, Linux can dump cores for a.out binaries. In practice, that
> code is pretty bitrotten and buggy. Does anyone want that code so much
> that they'd like to fix it, or can we just delete it?

I was asking myself the same question while doing

  10970e1b4be9 ("x86/a.out: Clear the dump structure initially")

especially since it is kinda hard to get the toolchain to even create an
a.out executable - your script to create one case-in-point.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-05  9:19 ` Borislav Petkov
@ 2019-03-05 12:22   ` Matthew Wilcox
  2019-03-05 13:43     ` Alan Cox
  2019-03-06 12:25     ` a.out coredumping: fix or delete? Thomas Gleixner
  0 siblings, 2 replies; 42+ messages in thread
From: Matthew Wilcox @ 2019-03-05 12:22 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API

On Tue, Mar 05, 2019 at 10:19:04AM +0100, Borislav Petkov wrote:
> On Sat, Mar 02, 2019 at 12:57:30AM +0100, Jann Horn wrote:
> > In theory, Linux can dump cores for a.out binaries. In practice, that
> > code is pretty bitrotten and buggy. Does anyone want that code so much
> > that they'd like to fix it, or can we just delete it?
> 
> I was asking myself the same question while doing
> 
>   10970e1b4be9 ("x86/a.out: Clear the dump structure initially")
> 
> especially since it is kinda hard to get the toolchain to even create an
> a.out executable - your script to create one case-in-point.

It's been 25 years since Linux added support for ELF.  Can we just
delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
support was added in 1.1.52 (August 1994).  It's pretty much necromancy
at this point.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-05 12:22   ` Matthew Wilcox
@ 2019-03-05 13:43     ` Alan Cox
  2019-03-05 14:59       ` [PATCH] x86: Deprecate a.out support Borislav Petkov
  2019-03-06 12:25     ` a.out coredumping: fix or delete? Thomas Gleixner
  1 sibling, 1 reply; 42+ messages in thread
From: Alan Cox @ 2019-03-05 13:43 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Borislav Petkov, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API

> It's been 25 years since Linux added support for ELF.  Can we just
> delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> at this point.

In the unlikely event that someone actually has an a.out binary they
can't live with they can also just write an a.out loader as an ELF
program entirely in userspace.

I'd vote for giving it the boot unless there are any architectures that
kept using a.out far longer due to tool chain issues ?

Alan

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH] x86: Deprecate a.out support
  2019-03-05 13:43     ` Alan Cox
@ 2019-03-05 14:59       ` Borislav Petkov
  2019-03-05 15:17         ` Richard Weinberger
  2019-03-05 16:22         ` Linus Torvalds
  0 siblings, 2 replies; 42+ messages in thread
From: Borislav Petkov @ 2019-03-05 14:59 UTC (permalink / raw)
  To: Alan Cox
  Cc: Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner, kernel list,
	linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Linus Torvalds, Richard Weinberger, Anton Ivanov

+ akpm and Linus.

On Tue, Mar 05, 2019 at 01:43:47PM +0000, Alan Cox wrote:
> > It's been 25 years since Linux added support for ELF.  Can we just
> > delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> > support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> > at this point.
> 
> In the unlikely event that someone actually has an a.out binary they
> can't live with they can also just write an a.out loader as an ELF
> program entirely in userspace.
> 
> I'd vote for giving it the boot unless there are any architectures that
> kept using a.out far longer due to tool chain issues ?

We can at least deprecate it on x86...

---
From: Borislav Petkov <bp@suse.de>
Date: Tue, 5 Mar 2019 15:47:51 +0100
Subject: [PATCH] x86: Deprecate a.out support

Linux supports ELF binaries for ~25 years now. a.out coredumping has
bitrotten quite significantly and would need some fixing to get it into
shape again but considering how even the toolchains cannot create a.out
executables in its default configuration, let's deprecate a.out support
and remove it a couple of releases later, instead.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Jann Horn <jannh@google.com>
Cc: <linux-api@vger.kernel.org>
Cc: <linux-fsdevel@vger.kernel.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <x86@kernel.org>
---
 arch/x86/Kconfig    | 2 +-
 arch/x86/um/Kconfig | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 68261430fe6e..ade12ec4224b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -14,7 +14,6 @@ config X86_32
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select CLKSRC_I8253
 	select CLONE_BACKWARDS
-	select HAVE_AOUT
 	select HAVE_GENERIC_DMA_COHERENT
 	select MODULES_USE_ELF_REL
 	select OLD_SIGACTION
@@ -2843,6 +2842,7 @@ config IA32_EMULATION
 config IA32_AOUT
 	tristate "IA32 a.out support"
 	depends on IA32_EMULATION
+	depends on BROKEN
 	---help---
 	  Support old a.out binaries in the 32bit emulation.
 
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index f518b4744ff8..494eeb51e4e1 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -16,7 +16,6 @@ config 64BIT
 
 config X86_32
 	def_bool !64BIT
-	select HAVE_AOUT
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select MODULES_USE_ELF_REL
 	select CLONE_BACKWARDS
-- 
2.21.0

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 14:59       ` [PATCH] x86: Deprecate a.out support Borislav Petkov
@ 2019-03-05 15:17         ` Richard Weinberger
  2019-03-05 16:22         ` Linus Torvalds
  1 sibling, 0 replies; 42+ messages in thread
From: Richard Weinberger @ 2019-03-05 15:17 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Linus Torvalds, Anton Ivanov

Am Dienstag, 5. März 2019, 15:59:52 CET schrieb Borislav Petkov:
> + akpm and Linus.
> 
> On Tue, Mar 05, 2019 at 01:43:47PM +0000, Alan Cox wrote:
> > > It's been 25 years since Linux added support for ELF.  Can we just
> > > delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> > > support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> > > at this point.
> > 
> > In the unlikely event that someone actually has an a.out binary they
> > can't live with they can also just write an a.out loader as an ELF
> > program entirely in userspace.
> > 
> > I'd vote for giving it the boot unless there are any architectures that
> > kept using a.out far longer due to tool chain issues ?
> 
> We can at least deprecate it on x86...
> 
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Tue, 5 Mar 2019 15:47:51 +0100
> Subject: [PATCH] x86: Deprecate a.out support
> 
> Linux supports ELF binaries for ~25 years now. a.out coredumping has
> bitrotten quite significantly and would need some fixing to get it into
> shape again but considering how even the toolchains cannot create a.out
> executables in its default configuration, let's deprecate a.out support
> and remove it a couple of releases later, instead.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> Cc: Jann Horn <jannh@google.com>
> Cc: <linux-api@vger.kernel.org>
> Cc: <linux-fsdevel@vger.kernel.org>
> Cc: lkml <linux-kernel@vger.kernel.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: <x86@kernel.org>
> ---
>  arch/x86/Kconfig    | 2 +-
>  arch/x86/um/Kconfig | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 68261430fe6e..ade12ec4224b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -14,7 +14,6 @@ config X86_32
>  	select ARCH_WANT_IPC_PARSE_VERSION
>  	select CLKSRC_I8253
>  	select CLONE_BACKWARDS
> -	select HAVE_AOUT
>  	select HAVE_GENERIC_DMA_COHERENT
>  	select MODULES_USE_ELF_REL
>  	select OLD_SIGACTION
> @@ -2843,6 +2842,7 @@ config IA32_EMULATION
>  config IA32_AOUT
>  	tristate "IA32 a.out support"
>  	depends on IA32_EMULATION
> +	depends on BROKEN
>  	---help---
>  	  Support old a.out binaries in the 32bit emulation.
>  
> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
> index f518b4744ff8..494eeb51e4e1 100644
> --- a/arch/x86/um/Kconfig
> +++ b/arch/x86/um/Kconfig
> @@ -16,7 +16,6 @@ config 64BIT
>  
>  config X86_32
>  	def_bool !64BIT
> -	select HAVE_AOUT
>  	select ARCH_WANT_IPC_PARSE_VERSION
>  	select MODULES_USE_ELF_REL
>  	select CLONE_BACKWARDS
> 

For UML,

Acked-by: Richard Weinberger <richard@nod.at>

Thanks,
//richard



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 14:59       ` [PATCH] x86: Deprecate a.out support Borislav Petkov
  2019-03-05 15:17         ` Richard Weinberger
@ 2019-03-05 16:22         ` Linus Torvalds
  2019-03-05 16:30           ` Jann Horn
                             ` (2 more replies)
  1 sibling, 3 replies; 42+ messages in thread
From: Linus Torvalds @ 2019-03-05 16:22 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov <bp@alien8.de> wrote:
>
> We can at least deprecate it on x86...

I'd prefer to try to deprecate a.out core dumping first.. That's the
part that is actually broken, no?

In fact, I'd be happy to deprecate a.out entirely, but if somebody
_does_ complain, I'd like to be able to bring it back without the core
dumping.

Because I think the likeliihood that anybody cares about a.out core
dumps is basically zero. While the likelihood that we have some odd
old binary that is still a.out is slightly above zero.

So I'd be much happier with this if it was a two-stage thing where we
just delete a.out core dumping entirely first, and then deprecate even
running a.out binaries separately.

Because I think all the known *bugs* we had were with the core dumping
code, weren't they?

Removing it looks trivial. Untested patch attached.

Then I'd be much happier with your "let's deprecate a.out entirely" as
a second patch, because I think it's a unrelated issue and much more
likely to have somebody pipe up and say "hey, I have this sequence
that generates executables dynamically, and I use a.out because it's
much simpler than ELF, and now it's broken". Or something.

           Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 8506 bytes --]

 arch/x86/ia32/ia32_aout.c | 159 ----------------------------------------------
 fs/binfmt_aout.c          |  82 ------------------------
 2 files changed, 241 deletions(-)

diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index 7dbbe9ffda17..3c135084e1eb 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -39,82 +39,10 @@
 static int load_aout_binary(struct linux_binprm *);
 static int load_aout_library(struct file *);
 
-#ifdef CONFIG_COREDUMP
-static int aout_core_dump(struct coredump_params *);
-
-static unsigned long get_dr(int n)
-{
-	struct perf_event *bp = current->thread.ptrace_bps[n];
-	return bp ? bp->hw.info.address : 0;
-}
-
-/*
- * fill in the user structure for a core dump..
- */
-static void fill_dump(struct pt_regs *regs, struct user32 *dump)
-{
-	u32 fs, gs;
-	memset(dump, 0, sizeof(*dump));
-
-/* changed the size calculations - should hopefully work better. lbt */
-	dump->magic = CMAGIC;
-	dump->start_code = 0;
-	dump->start_stack = regs->sp & ~(PAGE_SIZE - 1);
-	dump->u_tsize = ((unsigned long) current->mm->end_code) >> PAGE_SHIFT;
-	dump->u_dsize = ((unsigned long)
-			 (current->mm->brk + (PAGE_SIZE-1))) >> PAGE_SHIFT;
-	dump->u_dsize -= dump->u_tsize;
-	dump->u_debugreg[0] = get_dr(0);
-	dump->u_debugreg[1] = get_dr(1);
-	dump->u_debugreg[2] = get_dr(2);
-	dump->u_debugreg[3] = get_dr(3);
-	dump->u_debugreg[6] = current->thread.debugreg6;
-	dump->u_debugreg[7] = current->thread.ptrace_dr7;
-
-	if (dump->start_stack < 0xc0000000) {
-		unsigned long tmp;
-
-		tmp = (unsigned long) (0xc0000000 - dump->start_stack);
-		dump->u_ssize = tmp >> PAGE_SHIFT;
-	}
-
-	dump->regs.ebx = regs->bx;
-	dump->regs.ecx = regs->cx;
-	dump->regs.edx = regs->dx;
-	dump->regs.esi = regs->si;
-	dump->regs.edi = regs->di;
-	dump->regs.ebp = regs->bp;
-	dump->regs.eax = regs->ax;
-	dump->regs.ds = current->thread.ds;
-	dump->regs.es = current->thread.es;
-	savesegment(fs, fs);
-	dump->regs.fs = fs;
-	savesegment(gs, gs);
-	dump->regs.gs = gs;
-	dump->regs.orig_eax = regs->orig_ax;
-	dump->regs.eip = regs->ip;
-	dump->regs.cs = regs->cs;
-	dump->regs.eflags = regs->flags;
-	dump->regs.esp = regs->sp;
-	dump->regs.ss = regs->ss;
-
-#if 1 /* FIXME */
-	dump->u_fpvalid = 0;
-#else
-	dump->u_fpvalid = dump_fpu(regs, &dump->i387);
-#endif
-}
-
-#endif
-
 static struct linux_binfmt aout_format = {
 	.module		= THIS_MODULE,
 	.load_binary	= load_aout_binary,
 	.load_shlib	= load_aout_library,
-#ifdef CONFIG_COREDUMP
-	.core_dump	= aout_core_dump,
-#endif
-	.min_coredump	= PAGE_SIZE
 };
 
 static int set_brk(unsigned long start, unsigned long end)
@@ -126,93 +54,6 @@ static int set_brk(unsigned long start, unsigned long end)
 	return vm_brk(start, end - start);
 }
 
-#ifdef CONFIG_COREDUMP
-/*
- * These are the only things you should do on a core-file: use only these
- * macros to write out all the necessary info.
- */
-
-#include <linux/coredump.h>
-
-#define START_DATA(u)	(u.u_tsize << PAGE_SHIFT)
-#define START_STACK(u)	(u.start_stack)
-
-/*
- * Routine writes a core dump image in the current directory.
- * Currently only a stub-function.
- *
- * Note that setuid/setgid files won't make a core-dump if the uid/gid
- * changed due to the set[u|g]id. It's enforced by the "current->mm->dumpable"
- * field, which also makes sure the core-dumps won't be recursive if the
- * dumping of the process results in another error..
- */
-
-static int aout_core_dump(struct coredump_params *cprm)
-{
-	mm_segment_t fs;
-	int has_dumped = 0;
-	unsigned long dump_start, dump_size;
-	struct user32 dump;
-
-	fs = get_fs();
-	set_fs(KERNEL_DS);
-	has_dumped = 1;
-
-	fill_dump(cprm->regs, &dump);
-
-	strncpy(dump.u_comm, current->comm, sizeof(current->comm));
-	dump.u_ar0 = offsetof(struct user32, regs);
-	dump.signal = cprm->siginfo->si_signo;
-
-	/*
-	 * If the size of the dump file exceeds the rlimit, then see
-	 * what would happen if we wrote the stack, but not the data
-	 * area.
-	 */
-	if ((dump.u_dsize + dump.u_ssize + 1) * PAGE_SIZE > cprm->limit)
-		dump.u_dsize = 0;
-
-	/* Make sure we have enough room to write the stack and data areas. */
-	if ((dump.u_ssize + 1) * PAGE_SIZE > cprm->limit)
-		dump.u_ssize = 0;
-
-	/* make sure we actually have a data and stack area to dump */
-	set_fs(USER_DS);
-	if (!access_ok((void *) (unsigned long)START_DATA(dump),
-		       dump.u_dsize << PAGE_SHIFT))
-		dump.u_dsize = 0;
-	if (!access_ok((void *) (unsigned long)START_STACK(dump),
-		       dump.u_ssize << PAGE_SHIFT))
-		dump.u_ssize = 0;
-
-	set_fs(KERNEL_DS);
-	/* struct user */
-	if (!dump_emit(cprm, &dump, sizeof(dump)))
-		goto end_coredump;
-	/* Now dump all of the user data.  Include malloced stuff as well */
-	if (!dump_skip(cprm, PAGE_SIZE - sizeof(dump)))
-		goto end_coredump;
-	/* now we start writing out the user space info */
-	set_fs(USER_DS);
-	/* Dump the data area */
-	if (dump.u_dsize != 0) {
-		dump_start = START_DATA(dump);
-		dump_size = dump.u_dsize << PAGE_SHIFT;
-		if (!dump_emit(cprm, (void *)dump_start, dump_size))
-			goto end_coredump;
-	}
-	/* Now prepare to dump the stack area */
-	if (dump.u_ssize != 0) {
-		dump_start = START_STACK(dump);
-		dump_size = dump.u_ssize << PAGE_SHIFT;
-		if (!dump_emit(cprm, (void *)dump_start, dump_size))
-			goto end_coredump;
-	}
-end_coredump:
-	set_fs(fs);
-	return has_dumped;
-}
-#endif
 
 /*
  * create_aout_tables() parses the env- and arg-strings in new user
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index ca9725f18e00..aa0f1e53113f 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -34,92 +34,10 @@
 static int load_aout_binary(struct linux_binprm *);
 static int load_aout_library(struct file*);
 
-#ifdef CONFIG_COREDUMP
-/*
- * Routine writes a core dump image in the current directory.
- * Currently only a stub-function.
- *
- * Note that setuid/setgid files won't make a core-dump if the uid/gid
- * changed due to the set[u|g]id. It's enforced by the "current->mm->dumpable"
- * field, which also makes sure the core-dumps won't be recursive if the
- * dumping of the process results in another error..
- */
-static int aout_core_dump(struct coredump_params *cprm)
-{
-	mm_segment_t fs;
-	int has_dumped = 0;
-	void __user *dump_start;
-	int dump_size;
-	struct user dump;
-#ifdef __alpha__
-#       define START_DATA(u)	((void __user *)u.start_data)
-#else
-#	define START_DATA(u)	((void __user *)((u.u_tsize << PAGE_SHIFT) + \
-				 u.start_code))
-#endif
-#       define START_STACK(u)   ((void __user *)u.start_stack)
-
-	fs = get_fs();
-	set_fs(KERNEL_DS);
-	has_dumped = 1;
-       	strncpy(dump.u_comm, current->comm, sizeof(dump.u_comm));
-	dump.u_ar0 = offsetof(struct user, regs);
-	dump.signal = cprm->siginfo->si_signo;
-	aout_dump_thread(cprm->regs, &dump);
-
-/* If the size of the dump file exceeds the rlimit, then see what would happen
-   if we wrote the stack, but not the data area.  */
-	if ((dump.u_dsize + dump.u_ssize+1) * PAGE_SIZE > cprm->limit)
-		dump.u_dsize = 0;
-
-/* Make sure we have enough room to write the stack and data areas. */
-	if ((dump.u_ssize + 1) * PAGE_SIZE > cprm->limit)
-		dump.u_ssize = 0;
-
-/* make sure we actually have a data and stack area to dump */
-	set_fs(USER_DS);
-	if (!access_ok(START_DATA(dump), dump.u_dsize << PAGE_SHIFT))
-		dump.u_dsize = 0;
-	if (!access_ok(START_STACK(dump), dump.u_ssize << PAGE_SHIFT))
-		dump.u_ssize = 0;
-
-	set_fs(KERNEL_DS);
-/* struct user */
-	if (!dump_emit(cprm, &dump, sizeof(dump)))
-		goto end_coredump;
-/* Now dump all of the user data.  Include malloced stuff as well */
-	if (!dump_skip(cprm, PAGE_SIZE - sizeof(dump)))
-		goto end_coredump;
-/* now we start writing out the user space info */
-	set_fs(USER_DS);
-/* Dump the data area */
-	if (dump.u_dsize != 0) {
-		dump_start = START_DATA(dump);
-		dump_size = dump.u_dsize << PAGE_SHIFT;
-		if (!dump_emit(cprm, dump_start, dump_size))
-			goto end_coredump;
-	}
-/* Now prepare to dump the stack area */
-	if (dump.u_ssize != 0) {
-		dump_start = START_STACK(dump);
-		dump_size = dump.u_ssize << PAGE_SHIFT;
-		if (!dump_emit(cprm, dump_start, dump_size))
-			goto end_coredump;
-	}
-end_coredump:
-	set_fs(fs);
-	return has_dumped;
-}
-#else
-#define aout_core_dump NULL
-#endif
-
 static struct linux_binfmt aout_format = {
 	.module		= THIS_MODULE,
 	.load_binary	= load_aout_binary,
 	.load_shlib	= load_aout_library,
-	.core_dump	= aout_core_dump,
-	.min_coredump	= PAGE_SIZE
 };
 
 #define BAD_ADDR(x)	((unsigned long)(x) >= TASK_SIZE)

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 16:22         ` Linus Torvalds
@ 2019-03-05 16:30           ` Jann Horn
  2019-03-05 17:32             ` Borislav Petkov
  2019-03-05 17:31           ` Borislav Petkov
  2019-03-06 16:55           ` Enrico Weigelt, metux IT consult
  2 siblings, 1 reply; 42+ messages in thread
From: Jann Horn @ 2019-03-05 16:30 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Borislav Petkov, Alan Cox, Matthew Wilcox, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov

On Tue, Mar 5, 2019 at 5:22 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov <bp@alien8.de> wrote:
> > We can at least deprecate it on x86...
>
> I'd prefer to try to deprecate a.out core dumping first.. That's the
> part that is actually broken, no?
>
> In fact, I'd be happy to deprecate a.out entirely, but if somebody
> _does_ complain, I'd like to be able to bring it back without the core
> dumping.
>
> Because I think the likeliihood that anybody cares about a.out core
> dumps is basically zero. While the likelihood that we have some odd
> old binary that is still a.out is slightly above zero.
>
> So I'd be much happier with this if it was a two-stage thing where we
> just delete a.out core dumping entirely first, and then deprecate even
> running a.out binaries separately.
>
> Because I think all the known *bugs* we had were with the core dumping
> code, weren't they?
>
> Removing it looks trivial. Untested patch attached.

We might want to also delete the then-unused aout_dump_thread()
implementations from the various arch trees. We probably want to
delete arch/*/include/asm/a.out-core.h, since that seems to be the
only thing these headers do, and the only thing that uses them is
fs/binfmt_aout.c?

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 16:22         ` Linus Torvalds
  2019-03-05 16:30           ` Jann Horn
@ 2019-03-05 17:31           ` Borislav Petkov
  2019-03-05 17:58             ` Linus Torvalds
  2019-03-06 16:55           ` Enrico Weigelt, metux IT consult
  2 siblings, 1 reply; 42+ messages in thread
From: Borislav Petkov @ 2019-03-05 17:31 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov

On Tue, Mar 05, 2019 at 08:22:21AM -0800, Linus Torvalds wrote:
> Because I think all the known *bugs* we had were with the core dumping
> code, weren't they?

Well, I'm aware of only this one I fixed but who knows what else has
bitrotten out there through the years...

> Removing it looks trivial. Untested patch attached.
> 
> Then I'd be much happier with your "let's deprecate a.out entirely" as
> a second patch, because I think it's a unrelated issue and much more
> likely to have somebody pipe up and say "hey, I have this sequence
> that generates executables dynamically, and I use a.out because it's
> much simpler than ELF, and now it's broken". Or something.

Hohumm, yap, it all makes sense to me. That's definitely the safer
approach without us having to revert patches later.

So how do you wanna handle this?

I guess the easiest would be if you apply your patch directly now and
add the a.out phase-out strategy we're going for in its commit message
so that people are aware of what we're doing.

This will allow for other arch maintainers to delete
arch/*/include/asm/a.out-core.h, Jann mentions in the other mail, after
-rc1 is cut.

And then I'll carry any other patches through the tip tree ontop of -rc1
too.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 16:30           ` Jann Horn
@ 2019-03-05 17:32             ` Borislav Petkov
  0 siblings, 0 replies; 42+ messages in thread
From: Borislav Petkov @ 2019-03-05 17:32 UTC (permalink / raw)
  To: Jann Horn
  Cc: Linus Torvalds, Alan Cox, Matthew Wilcox, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov

On Tue, Mar 05, 2019 at 05:30:13PM +0100, Jann Horn wrote:
> We might want to also delete the then-unused aout_dump_thread()
> implementations from the various arch trees. We probably want to
> delete arch/*/include/asm/a.out-core.h, since that seems to be the
> only thing these headers do, and the only thing that uses them is
> fs/binfmt_aout.c?

Right.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 17:31           ` Borislav Petkov
@ 2019-03-05 17:58             ` Linus Torvalds
  2019-03-05 18:11               ` Borislav Petkov
  0 siblings, 1 reply; 42+ messages in thread
From: Linus Torvalds @ 2019-03-05 17:58 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov

On Tue, Mar 5, 2019 at 9:31 AM Borislav Petkov <bp@alien8.de> wrote:
>
> So how do you wanna handle this?
>
> I guess the easiest would be if you apply your patch directly now and
> add the a.out phase-out strategy we're going for in its commit message
> so that people are aware of what we're doing.

Yup, I'll just do that. I'll fix up my patch to be more complete (ie
the a.out-core.h removal Jann pointed out).

I'll talk about removing a.out support entirely in the commit message.
I'd be ok for that to be a total removal, but maybe there are some
architectures that still have that as a "main" format?

Or I could just apply your patch after removing the core-dumping. Comments?

               Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 17:58             ` Linus Torvalds
@ 2019-03-05 18:11               ` Borislav Petkov
  2019-03-05 18:18                 ` Borislav Petkov
  0 siblings, 1 reply; 42+ messages in thread
From: Borislav Petkov @ 2019-03-05 18:11 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov

On Tue, Mar 05, 2019 at 09:58:28AM -0800, Linus Torvalds wrote:
> I'd be ok for that to be a total removal, but maybe there are some
> architectures that still have that as a "main" format?

Well, my limited experience with feature removal says that people only
say something when the feature is *actually* long gone, several releases
have passed by and the removal has finally percolated downstream.

I guess you could Cc arch maintainers with the a.out-core.h removal
patch to see if anyone screams.

> Or I could just apply your patch after removing the core-dumping. Comments?

Sure. And it can be reverted very easily if someone runs out of the
woods later and handwaving about an important a.out use case on x86.
Although x86 should be in ELF-land for a quarter of a decade now.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 18:11               ` Borislav Petkov
@ 2019-03-05 18:18                 ` Borislav Petkov
  2019-03-06 15:07                   ` Geert Uytterhoeven
  2019-03-10 21:37                   ` Matt Turner
  0 siblings, 2 replies; 42+ messages in thread
From: Borislav Petkov @ 2019-03-05 18:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov, linux-alpha,
	linux-m68k

On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> I guess you could Cc arch maintainers with the a.out-core.h removal
> patch to see if anyone screams.

And they're like two for which we need confirmation:

$ git ls-files | grep a.out-core.h
arch/alpha/include/asm/a.out-core.h
arch/m68k/include/asm/a.out-core.h
arch/um/include/asm/a.out-core.h
arch/x86/include/asm/a.out-core.h

um and x86 are clear.

Adding alpha and m68k MLs to Cc.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-05 12:22   ` Matthew Wilcox
  2019-03-05 13:43     ` Alan Cox
@ 2019-03-06 12:25     ` Thomas Gleixner
  2019-03-06 14:11       ` Theodore Y. Ts'o
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas Gleixner @ 2019-03-06 12:25 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Borislav Petkov, Jann Horn, Al Viro, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API

On Tue, 5 Mar 2019, Matthew Wilcox wrote:
> On Tue, Mar 05, 2019 at 10:19:04AM +0100, Borislav Petkov wrote:
> > On Sat, Mar 02, 2019 at 12:57:30AM +0100, Jann Horn wrote:
> > > In theory, Linux can dump cores for a.out binaries. In practice, that
> > > code is pretty bitrotten and buggy. Does anyone want that code so much
> > > that they'd like to fix it, or can we just delete it?
> > 
> > I was asking myself the same question while doing
> > 
> >   10970e1b4be9 ("x86/a.out: Clear the dump structure initially")
> > 
> > especially since it is kinda hard to get the toolchain to even create an
> > a.out executable - your script to create one case-in-point.
> 
> It's been 25 years since Linux added support for ELF.  Can we just
> delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> at this point.

The Kernel-Necrophilia cult members might disagree. :)

But yes, good riddance.

Thanks,

	tglx


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-06 12:25     ` a.out coredumping: fix or delete? Thomas Gleixner
@ 2019-03-06 14:11       ` Theodore Y. Ts'o
  2019-03-06 16:52         ` Alan Cox
  0 siblings, 1 reply; 42+ messages in thread
From: Theodore Y. Ts'o @ 2019-03-06 14:11 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Matthew Wilcox, Borislav Petkov, Jann Horn, Al Viro, kernel list,
	linux-fsdevel, the arch/x86 maintainers, Linux API

On Wed, Mar 06, 2019 at 01:25:17PM +0100, Thomas Gleixner wrote:
> > It's been 25 years since Linux added support for ELF.  Can we just
> > delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> > support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> > at this point.
> 
> The Kernel-Necrophilia cult members might disagree. :)
> 
> But yes, good riddance.

Doesn't Minix 1.0 use a.out?  It *is* cool to be able to binaries from
run dead operating systems.  :-)

						- Ted

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 18:18                 ` Borislav Petkov
@ 2019-03-06 15:07                   ` Geert Uytterhoeven
  2019-03-10 21:37                   ` Matt Turner
  1 sibling, 0 replies; 42+ messages in thread
From: Geert Uytterhoeven @ 2019-03-06 15:07 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Linus Torvalds, Alan Cox, Matthew Wilcox, Jann Horn, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, alpha, linux-m68k

Hi Borislav,

On Tue, Mar 5, 2019 at 8:04 PM Borislav Petkov <bp@alien8.de> wrote:
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need confirmation:
>
> $ git ls-files | grep a.out-core.h
> arch/alpha/include/asm/a.out-core.h
> arch/m68k/include/asm/a.out-core.h
> arch/um/include/asm/a.out-core.h
> arch/x86/include/asm/a.out-core.h
>
> um and x86 are clear.
>
> Adding alpha and m68k MLs to Cc.

Thanks!

The oldest binaries I still have lying around (an ext2 ramdisk image,
still used from time to time) are ELF, from just after the a.out to ELF
transition on m68k.

I think it's safe to assume no one still runs a.out binaries on m68k.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-06 14:11       ` Theodore Y. Ts'o
@ 2019-03-06 16:52         ` Alan Cox
  2019-03-06 17:45           ` Andy Lutomirski
  0 siblings, 1 reply; 42+ messages in thread
From: Alan Cox @ 2019-03-06 16:52 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Thomas Gleixner, Matthew Wilcox, Borislav Petkov, Jann Horn,
	Al Viro, kernel list, linux-fsdevel, the arch/x86 maintainers,
	Linux API

On Wed, 6 Mar 2019 09:11:44 -0500
"Theodore Y. Ts'o" <tytso@mit.edu> wrote:

> On Wed, Mar 06, 2019 at 01:25:17PM +0100, Thomas Gleixner wrote:
> > > It's been 25 years since Linux added support for ELF.  Can we just
> > > delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> > > support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> > > at this point.  
> > 
> > The Kernel-Necrophilia cult members might disagree. :)
> > 
> > But yes, good riddance.  
> 
> Doesn't Minix 1.0 use a.out?  It *is* cool to be able to binaries from
> run dead operating systems.  :-)

Minixemu compiled fine ELF last time I checked 8). It does need  a 32bit
system as it still uses virtual 86 model.

Alan

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 16:22         ` Linus Torvalds
  2019-03-05 16:30           ` Jann Horn
  2019-03-05 17:31           ` Borislav Petkov
@ 2019-03-06 16:55           ` Enrico Weigelt, metux IT consult
  2019-03-06 17:52             ` [PATCH] fs: binfmt: mark aout as broken Enrico Weigelt, metux IT consult
  2 siblings, 1 reply; 42+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2019-03-06 16:55 UTC (permalink / raw)
  To: Linus Torvalds, Borislav Petkov
  Cc: Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov

On 05.03.19 17:22, Linus Torvalds wrote:
> On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov <bp@alien8.de> wrote:
>>
>> We can at least deprecate it on x86...
> 
> I'd prefer to try to deprecate a.out core dumping first.. That's the
> part that is actually broken, no?
> 
> In fact, I'd be happy to deprecate a.out entirely, but if somebody
> _does_ complain, I'd like to be able to bring it back without the core
> dumping.

Maybe make it depend on BROKEN ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: a.out coredumping: fix or delete?
  2019-03-06 16:52         ` Alan Cox
@ 2019-03-06 17:45           ` Andy Lutomirski
  0 siblings, 0 replies; 42+ messages in thread
From: Andy Lutomirski @ 2019-03-06 17:45 UTC (permalink / raw)
  To: Alan Cox
  Cc: Theodore Y. Ts'o, Thomas Gleixner, Matthew Wilcox,
	Borislav Petkov, Jann Horn, Al Viro, kernel list, Linux FS Devel,
	the arch/x86 maintainers, Linux API

On Wed, Mar 6, 2019 at 8:53 AM Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>
> On Wed, 6 Mar 2019 09:11:44 -0500
> "Theodore Y. Ts'o" <tytso@mit.edu> wrote:
>
> > On Wed, Mar 06, 2019 at 01:25:17PM +0100, Thomas Gleixner wrote:
> > > > It's been 25 years since Linux added support for ELF.  Can we just
> > > > delete the a.out support entirely now?  According to the Linux-ELF HOWTO,
> > > > support was added in 1.1.52 (August 1994).  It's pretty much necromancy
> > > > at this point.
> > >
> > > The Kernel-Necrophilia cult members might disagree. :)
> > >
> > > But yes, good riddance.
> >
> > Doesn't Minix 1.0 use a.out?  It *is* cool to be able to binaries from
> > run dead operating systems.  :-)
>
> Minixemu compiled fine ELF last time I checked 8). It does need  a 32bit
> system as it still uses virtual 86 model.
>

While I consider vm86() to be a giant turd, I also consider it to be
supported and even wrote it a somewhat decent test suite :)

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH] fs: binfmt: mark aout as broken
  2019-03-06 16:55           ` Enrico Weigelt, metux IT consult
@ 2019-03-06 17:52             ` Enrico Weigelt, metux IT consult
  0 siblings, 0 replies; 42+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2019-03-06 17:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: viro, linux-fsdevel

Core dumping is pretty broken, and nobody seriously seems to use
that ancient binfmt anymore.

In the longer run, it probably will be removed. But once that's
done, it'll take some time to propagate through the distros and
hit somebody who really needs it, and reverting will be difficult.

Therefore, markt it BROKEN right now, sit back and just wait for
somebody complaining :p

Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
 fs/Kconfig.binfmt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index b795f8d..05074f4 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -115,6 +115,7 @@ config HAVE_AOUT
 config BINFMT_AOUT
 	tristate "Kernel support for a.out and ECOFF binaries"
 	depends on HAVE_AOUT
+	depends on BROKEN
 	---help---
 	  A.out (Assembler.OUTput) is a set of formats for libraries and
 	  executables used in the earliest versions of UNIX.  Linux used
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-05 18:18                 ` Borislav Petkov
  2019-03-06 15:07                   ` Geert Uytterhoeven
@ 2019-03-10 21:37                   ` Matt Turner
  2019-03-10 22:40                     ` Linus Torvalds
  1 sibling, 1 reply; 42+ messages in thread
From: Matt Turner @ 2019-03-10 21:37 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Linus Torvalds, Alan Cox, Matthew Wilcox, Jann Horn, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Tue, Mar 5, 2019 at 11:04 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote:
> > I guess you could Cc arch maintainers with the a.out-core.h removal
> > patch to see if anyone screams.
>
> And they're like two for which we need confirmation:
>
> $ git ls-files | grep a.out-core.h
> arch/alpha/include/asm/a.out-core.h
> arch/m68k/include/asm/a.out-core.h
> arch/um/include/asm/a.out-core.h
> arch/x86/include/asm/a.out-core.h
>
> um and x86 are clear.
>
> Adding alpha and m68k MLs to Cc.

I'm not aware of a reason to keep a.out support on alpha.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-10 21:37                   ` Matt Turner
@ 2019-03-10 22:40                     ` Linus Torvalds
  2019-03-10 23:19                       ` Al Viro
                                         ` (3 more replies)
  0 siblings, 4 replies; 42+ messages in thread
From: Linus Torvalds @ 2019-03-10 22:40 UTC (permalink / raw)
  To: Matt Turner
  Cc: Borislav Petkov, Alan Cox, Matthew Wilcox, Jann Horn, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <mattst88@gmail.com> wrote:
>
> I'm not aware of a reason to keep a.out support on alpha.

Hmm. I was looking at removing a.out support entirely, but it's
actually fairly incestuous on alpha.

For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
support in it. Maybe it can just be removed entirely.

There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c.

Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense
without a.out support.

So this attached patch does not compile on alpha, but it's been many
many years since I had an alpha to test with, so I'm stuck.

Matt, can you fill in the details and complete this patch?

                      Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 23855 bytes --]

 arch/alpha/Kconfig          |   1 -
 arch/alpha/kernel/osf_sys.c |  30 ----
 arch/m68k/Kconfig           |   1 -
 arch/x86/Kconfig            |   7 -
 arch/x86/ia32/Makefile      |   2 -
 arch/x86/ia32/ia32_aout.c   | 330 ------------------------------------------
 fs/Kconfig.binfmt           |  33 -----
 fs/Makefile                 |   1 -
 fs/binfmt_aout.c            | 343 --------------------------------------------
 include/linux/a.out.h       |  18 ---
 10 files changed, 766 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 584a6e114853..9b9770b45f36 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -10,7 +10,6 @@ config ALPHA
 	select FORCE_PCI if !ALPHA_JENSEN
 	select PCI_DOMAINS if PCI
 	select PCI_SYSCALL if PCI
-	select HAVE_AOUT
 	select HAVE_IDE
 	select HAVE_OPROFILE
 	select HAVE_PCSPKR_PLATFORM
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index bf497b8b0ec6..09a0746c9681 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1342,45 +1342,15 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 	return addr;
 }
 
-#ifdef CONFIG_OSF4_COMPAT
-/* Clear top 32 bits of iov_len in the user's buffer for
-   compatibility with old versions of OSF/1 where iov_len
-   was defined as int. */
-static int
-osf_fix_iov_len(const struct iovec __user *iov, unsigned long count)
-{
-	unsigned long i;
-
-	for (i = 0 ; i < count ; i++) {
-		int __user *iov_len_high = (int __user *)&iov[i].iov_len + 1;
-
-		if (put_user(0, iov_len_high))
-			return -EFAULT;
-	}
-	return 0;
-}
-#endif
-
 SYSCALL_DEFINE3(osf_readv, unsigned long, fd,
 		const struct iovec __user *, vector, unsigned long, count)
 {
-#ifdef CONFIG_OSF4_COMPAT
-	if (unlikely(personality(current->personality) == PER_OSF4))
-		if (osf_fix_iov_len(vector, count))
-			return -EFAULT;
-#endif
-
 	return sys_readv(fd, vector, count);
 }
 
 SYSCALL_DEFINE3(osf_writev, unsigned long, fd,
 		const struct iovec __user *, vector, unsigned long, count)
 {
-#ifdef CONFIG_OSF4_COMPAT
-	if (unlikely(personality(current->personality) == PER_OSF4))
-		if (osf_fix_iov_len(vector, count))
-			return -EFAULT;
-#endif
 	return sys_writev(fd, vector, count);
 }
 
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index b54206408f91..65d263c60669 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -8,7 +8,6 @@ config M68K
 	select ARCH_NO_COHERENT_DMA_MMAP if !MMU
 	select ARCH_NO_PREEMPT if !COLDFIRE
 	select HAVE_IDE
-	select HAVE_AOUT if MMU
 	select HAVE_DEBUG_BUGVERBOSE
 	select GENERIC_IRQ_SHOW
 	select GENERIC_ATOMIC64
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c1f9b3cf437c..4a9438e4fba6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2836,13 +2836,6 @@ config IA32_EMULATION
 	  64-bit kernel. You should likely turn this on, unless you're
 	  100% sure that you don't have any 32-bit programs left.
 
-config IA32_AOUT
-	tristate "IA32 a.out support"
-	depends on IA32_EMULATION
-	depends on BROKEN
-	---help---
-	  Support old a.out binaries in the 32bit emulation.
-
 config X86_X32
 	bool "x32 ABI for 64-bit mode"
 	depends on X86_64
diff --git a/arch/x86/ia32/Makefile b/arch/x86/ia32/Makefile
index cd4339bae066..b98fedaa7642 100644
--- a/arch/x86/ia32/Makefile
+++ b/arch/x86/ia32/Makefile
@@ -4,7 +4,5 @@
 
 obj-$(CONFIG_IA32_EMULATION) := sys_ia32.o ia32_signal.o
 
-obj-$(CONFIG_IA32_AOUT) += ia32_aout.o
-
 audit-class-$(CONFIG_AUDIT) := audit.o
 obj-$(CONFIG_IA32_EMULATION) += $(audit-class-y)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
deleted file mode 100644
index 3c135084e1eb..000000000000
--- a/arch/x86/ia32/ia32_aout.c
+++ /dev/null
@@ -1,330 +0,0 @@
-/*
- *  a.out loader for x86-64
- *
- *  Copyright (C) 1991, 1992, 1996  Linus Torvalds
- *  Hacked together by Andi Kleen
- */
-
-#include <linux/module.h>
-
-#include <linux/time.h>
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/a.out.h>
-#include <linux/errno.h>
-#include <linux/signal.h>
-#include <linux/string.h>
-#include <linux/fs.h>
-#include <linux/file.h>
-#include <linux/stat.h>
-#include <linux/fcntl.h>
-#include <linux/ptrace.h>
-#include <linux/user.h>
-#include <linux/binfmts.h>
-#include <linux/personality.h>
-#include <linux/init.h>
-#include <linux/jiffies.h>
-#include <linux/perf_event.h>
-#include <linux/sched/task_stack.h>
-
-#include <linux/uaccess.h>
-#include <asm/pgalloc.h>
-#include <asm/cacheflush.h>
-#include <asm/user32.h>
-#include <asm/ia32.h>
-
-#undef WARN_OLD
-
-static int load_aout_binary(struct linux_binprm *);
-static int load_aout_library(struct file *);
-
-static struct linux_binfmt aout_format = {
-	.module		= THIS_MODULE,
-	.load_binary	= load_aout_binary,
-	.load_shlib	= load_aout_library,
-};
-
-static int set_brk(unsigned long start, unsigned long end)
-{
-	start = PAGE_ALIGN(start);
-	end = PAGE_ALIGN(end);
-	if (end <= start)
-		return 0;
-	return vm_brk(start, end - start);
-}
-
-
-/*
- * create_aout_tables() parses the env- and arg-strings in new user
- * memory and creates the pointer tables from them, and puts their
- * addresses on the "stack", returning the new stack pointer value.
- */
-static u32 __user *create_aout_tables(char __user *p, struct linux_binprm *bprm)
-{
-	u32 __user *argv, *envp, *sp;
-	int argc = bprm->argc, envc = bprm->envc;
-
-	sp = (u32 __user *) ((-(unsigned long)sizeof(u32)) & (unsigned long) p);
-	sp -= envc+1;
-	envp = sp;
-	sp -= argc+1;
-	argv = sp;
-	put_user((unsigned long) envp, --sp);
-	put_user((unsigned long) argv, --sp);
-	put_user(argc, --sp);
-	current->mm->arg_start = (unsigned long) p;
-	while (argc-- > 0) {
-		char c;
-
-		put_user((u32)(unsigned long)p, argv++);
-		do {
-			get_user(c, p++);
-		} while (c);
-	}
-	put_user(0, argv);
-	current->mm->arg_end = current->mm->env_start = (unsigned long) p;
-	while (envc-- > 0) {
-		char c;
-
-		put_user((u32)(unsigned long)p, envp++);
-		do {
-			get_user(c, p++);
-		} while (c);
-	}
-	put_user(0, envp);
-	current->mm->env_end = (unsigned long) p;
-	return sp;
-}
-
-/*
- * These are the functions used to load a.out style executables and shared
- * libraries.  There is no binary dependent code anywhere else.
- */
-static int load_aout_binary(struct linux_binprm *bprm)
-{
-	unsigned long error, fd_offset, rlim;
-	struct pt_regs *regs = current_pt_regs();
-	struct exec ex;
-	int retval;
-
-	ex = *((struct exec *) bprm->buf);		/* exec-header */
-	if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
-	     N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
-	    N_TRSIZE(ex) || N_DRSIZE(ex) ||
-	    i_size_read(file_inode(bprm->file)) <
-	    ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
-		return -ENOEXEC;
-	}
-
-	fd_offset = N_TXTOFF(ex);
-
-	/* Check initial limits. This avoids letting people circumvent
-	 * size limits imposed on them by creating programs with large
-	 * arrays in the data or bss.
-	 */
-	rlim = rlimit(RLIMIT_DATA);
-	if (rlim >= RLIM_INFINITY)
-		rlim = ~0;
-	if (ex.a_data + ex.a_bss > rlim)
-		return -ENOMEM;
-
-	/* Flush all traces of the currently running executable */
-	retval = flush_old_exec(bprm);
-	if (retval)
-		return retval;
-
-	/* OK, This is the point of no return */
-	set_personality(PER_LINUX);
-	set_personality_ia32(false);
-
-	setup_new_exec(bprm);
-
-	regs->cs = __USER32_CS;
-	regs->r8 = regs->r9 = regs->r10 = regs->r11 = regs->r12 =
-		regs->r13 = regs->r14 = regs->r15 = 0;
-
-	current->mm->end_code = ex.a_text +
-		(current->mm->start_code = N_TXTADDR(ex));
-	current->mm->end_data = ex.a_data +
-		(current->mm->start_data = N_DATADDR(ex));
-	current->mm->brk = ex.a_bss +
-		(current->mm->start_brk = N_BSSADDR(ex));
-
-	retval = setup_arg_pages(bprm, IA32_STACK_TOP, EXSTACK_DEFAULT);
-	if (retval < 0)
-		return retval;
-
-	install_exec_creds(bprm);
-
-	if (N_MAGIC(ex) == OMAGIC) {
-		unsigned long text_addr, map_size;
-
-		text_addr = N_TXTADDR(ex);
-		map_size = ex.a_text+ex.a_data;
-
-		error = vm_brk(text_addr & PAGE_MASK, map_size);
-
-		if (error)
-			return error;
-
-		error = read_code(bprm->file, text_addr, 32,
-				  ex.a_text + ex.a_data);
-		if ((signed long)error < 0)
-			return error;
-	} else {
-#ifdef WARN_OLD
-		static unsigned long error_time, error_time2;
-		if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
-		    (N_MAGIC(ex) != NMAGIC) &&
-				time_after(jiffies, error_time2 + 5*HZ)) {
-			printk(KERN_NOTICE "executable not page aligned\n");
-			error_time2 = jiffies;
-		}
-
-		if ((fd_offset & ~PAGE_MASK) != 0 &&
-			    time_after(jiffies, error_time + 5*HZ)) {
-			printk(KERN_WARNING
-			       "fd_offset is not page aligned. Please convert "
-			       "program: %pD\n",
-			       bprm->file);
-			error_time = jiffies;
-		}
-#endif
-
-		if (!bprm->file->f_op->mmap || (fd_offset & ~PAGE_MASK) != 0) {
-			error = vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
-			if (error)
-				return error;
-
-			read_code(bprm->file, N_TXTADDR(ex), fd_offset,
-					ex.a_text+ex.a_data);
-			goto beyond_if;
-		}
-
-		error = vm_mmap(bprm->file, N_TXTADDR(ex), ex.a_text,
-				PROT_READ | PROT_EXEC,
-				MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE |
-				MAP_EXECUTABLE | MAP_32BIT,
-				fd_offset);
-
-		if (error != N_TXTADDR(ex))
-			return error;
-
-		error = vm_mmap(bprm->file, N_DATADDR(ex), ex.a_data,
-				PROT_READ | PROT_WRITE | PROT_EXEC,
-				MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE |
-				MAP_EXECUTABLE | MAP_32BIT,
-				fd_offset + ex.a_text);
-		if (error != N_DATADDR(ex))
-			return error;
-	}
-
-beyond_if:
-	error = set_brk(current->mm->start_brk, current->mm->brk);
-	if (error)
-		return error;
-
-	set_binfmt(&aout_format);
-
-	current->mm->start_stack =
-		(unsigned long)create_aout_tables((char __user *)bprm->p, bprm);
-	/* start thread */
-	loadsegment(fs, 0);
-	loadsegment(ds, __USER32_DS);
-	loadsegment(es, __USER32_DS);
-	load_gs_index(0);
-	(regs)->ip = ex.a_entry;
-	(regs)->sp = current->mm->start_stack;
-	(regs)->flags = 0x200;
-	(regs)->cs = __USER32_CS;
-	(regs)->ss = __USER32_DS;
-	regs->r8 = regs->r9 = regs->r10 = regs->r11 =
-	regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
-	set_fs(USER_DS);
-	return 0;
-}
-
-static int load_aout_library(struct file *file)
-{
-	unsigned long bss, start_addr, len, error;
-	int retval;
-	struct exec ex;
-	loff_t pos = 0;
-
-	retval = -ENOEXEC;
-	error = kernel_read(file, &ex, sizeof(ex), &pos);
-	if (error != sizeof(ex))
-		goto out;
-
-	/* We come in here for the regular a.out style of shared libraries */
-	if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
-	    N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
-	    i_size_read(file_inode(file)) <
-	    ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
-		goto out;
-	}
-
-	if (N_FLAGS(ex))
-		goto out;
-
-	/* For  QMAGIC, the starting address is 0x20 into the page.  We mask
-	   this off to get the starting address for the page */
-
-	start_addr =  ex.a_entry & 0xfffff000;
-
-	if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
-#ifdef WARN_OLD
-		static unsigned long error_time;
-		if (time_after(jiffies, error_time + 5*HZ)) {
-			printk(KERN_WARNING
-			       "N_TXTOFF is not page aligned. Please convert "
-			       "library: %pD\n",
-			       file);
-			error_time = jiffies;
-		}
-#endif
-		retval = vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
-		if (retval)
-			goto out;
-
-		read_code(file, start_addr, N_TXTOFF(ex),
-			  ex.a_text + ex.a_data);
-		retval = 0;
-		goto out;
-	}
-	/* Now use mmap to map the library into memory. */
-	error = vm_mmap(file, start_addr, ex.a_text + ex.a_data,
-			PROT_READ | PROT_WRITE | PROT_EXEC,
-			MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE | MAP_32BIT,
-			N_TXTOFF(ex));
-	retval = error;
-	if (error != start_addr)
-		goto out;
-
-	len = PAGE_ALIGN(ex.a_text + ex.a_data);
-	bss = ex.a_text + ex.a_data + ex.a_bss;
-	if (bss > len) {
-		retval = vm_brk(start_addr + len, bss - len);
-		if (retval)
-			goto out;
-	}
-	retval = 0;
-out:
-	return retval;
-}
-
-static int __init init_aout_binfmt(void)
-{
-	register_binfmt(&aout_format);
-	return 0;
-}
-
-static void __exit exit_aout_binfmt(void)
-{
-	unregister_binfmt(&aout_format);
-}
-
-module_init(init_aout_binfmt);
-module_exit(exit_aout_binfmt);
-MODULE_LICENSE("GPL");
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index b795f8da81f3..b4dfd2a92d95 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -109,39 +109,6 @@ config BINFMT_SHARED_FLAT
 	help
 	  Support FLAT shared libraries
 
-config HAVE_AOUT
-       def_bool n
-
-config BINFMT_AOUT
-	tristate "Kernel support for a.out and ECOFF binaries"
-	depends on HAVE_AOUT
-	---help---
-	  A.out (Assembler.OUTput) is a set of formats for libraries and
-	  executables used in the earliest versions of UNIX.  Linux used
-	  the a.out formats QMAGIC and ZMAGIC until they were replaced
-	  with the ELF format.
-
-	  The conversion to ELF started in 1995.  This option is primarily
-	  provided for historical interest and for the benefit of those
-	  who need to run binaries from that era.
-
-	  Most people should answer N here.  If you think you may have
-	  occasional use for this format, enable module support above
-	  and answer M here to compile this support as a module called
-	  binfmt_aout.
-
-	  If any crucial components of your system (such as /sbin/init
-	  or /lib/ld.so) are still in a.out format, you will have to
-	  say Y here.
-
-config OSF4_COMPAT
-	bool "OSF/1 v4 readv/writev compatibility"
-	depends on ALPHA && BINFMT_AOUT
-	help
-	  Say Y if you are using OSF/1 binaries (like Netscape and Acrobat)
-	  with v4 shared libraries freely available from Compaq. If you're
-	  going to use shared libraries from Tru64 version 5.0 or later, say N.
-
 config BINFMT_EM86
 	tristate "Kernel support for Linux/Intel ELF binaries"
 	depends on ALPHA
diff --git a/fs/Makefile b/fs/Makefile
index 7bff9abecfa4..0105e3496259 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -36,7 +36,6 @@ obj-$(CONFIG_FS_DAX)		+= dax.o
 obj-$(CONFIG_FS_ENCRYPTION)	+= crypto/
 obj-$(CONFIG_FILE_LOCKING)      += locks.o
 obj-$(CONFIG_COMPAT)		+= compat.o compat_ioctl.o
-obj-$(CONFIG_BINFMT_AOUT)	+= binfmt_aout.o
 obj-$(CONFIG_BINFMT_EM86)	+= binfmt_em86.o
 obj-$(CONFIG_BINFMT_MISC)	+= binfmt_misc.o
 obj-$(CONFIG_BINFMT_SCRIPT)	+= binfmt_script.o
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
deleted file mode 100644
index 1fefd87eb4b4..000000000000
--- a/fs/binfmt_aout.c
+++ /dev/null
@@ -1,343 +0,0 @@
-/*
- *  linux/fs/binfmt_aout.c
- *
- *  Copyright (C) 1991, 1992, 1996  Linus Torvalds
- */
-
-#include <linux/module.h>
-
-#include <linux/time.h>
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/a.out.h>
-#include <linux/errno.h>
-#include <linux/signal.h>
-#include <linux/string.h>
-#include <linux/fs.h>
-#include <linux/file.h>
-#include <linux/stat.h>
-#include <linux/fcntl.h>
-#include <linux/ptrace.h>
-#include <linux/user.h>
-#include <linux/binfmts.h>
-#include <linux/personality.h>
-#include <linux/init.h>
-#include <linux/coredump.h>
-#include <linux/slab.h>
-#include <linux/sched/task_stack.h>
-
-#include <linux/uaccess.h>
-#include <asm/cacheflush.h>
-
-static int load_aout_binary(struct linux_binprm *);
-static int load_aout_library(struct file*);
-
-static struct linux_binfmt aout_format = {
-	.module		= THIS_MODULE,
-	.load_binary	= load_aout_binary,
-	.load_shlib	= load_aout_library,
-};
-
-#define BAD_ADDR(x)	((unsigned long)(x) >= TASK_SIZE)
-
-static int set_brk(unsigned long start, unsigned long end)
-{
-	start = PAGE_ALIGN(start);
-	end = PAGE_ALIGN(end);
-	if (end > start)
-		return vm_brk(start, end - start);
-	return 0;
-}
-
-/*
- * create_aout_tables() parses the env- and arg-strings in new user
- * memory and creates the pointer tables from them, and puts their
- * addresses on the "stack", returning the new stack pointer value.
- */
-static unsigned long __user *create_aout_tables(char __user *p, struct linux_binprm * bprm)
-{
-	char __user * __user *argv;
-	char __user * __user *envp;
-	unsigned long __user *sp;
-	int argc = bprm->argc;
-	int envc = bprm->envc;
-
-	sp = (void __user *)((-(unsigned long)sizeof(char *)) & (unsigned long) p);
-#ifdef __alpha__
-/* whee.. test-programs are so much fun. */
-	put_user(0, --sp);
-	put_user(0, --sp);
-	if (bprm->loader) {
-		put_user(0, --sp);
-		put_user(1003, --sp);
-		put_user(bprm->loader, --sp);
-		put_user(1002, --sp);
-	}
-	put_user(bprm->exec, --sp);
-	put_user(1001, --sp);
-#endif
-	sp -= envc+1;
-	envp = (char __user * __user *) sp;
-	sp -= argc+1;
-	argv = (char __user * __user *) sp;
-#ifndef __alpha__
-	put_user((unsigned long) envp,--sp);
-	put_user((unsigned long) argv,--sp);
-#endif
-	put_user(argc,--sp);
-	current->mm->arg_start = (unsigned long) p;
-	while (argc-->0) {
-		char c;
-		put_user(p,argv++);
-		do {
-			get_user(c,p++);
-		} while (c);
-	}
-	put_user(NULL,argv);
-	current->mm->arg_end = current->mm->env_start = (unsigned long) p;
-	while (envc-->0) {
-		char c;
-		put_user(p,envp++);
-		do {
-			get_user(c,p++);
-		} while (c);
-	}
-	put_user(NULL,envp);
-	current->mm->env_end = (unsigned long) p;
-	return sp;
-}
-
-/*
- * These are the functions used to load a.out style executables and shared
- * libraries.  There is no binary dependent code anywhere else.
- */
-
-static int load_aout_binary(struct linux_binprm * bprm)
-{
-	struct pt_regs *regs = current_pt_regs();
-	struct exec ex;
-	unsigned long error;
-	unsigned long fd_offset;
-	unsigned long rlim;
-	int retval;
-
-	ex = *((struct exec *) bprm->buf);		/* exec-header */
-	if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
-	     N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
-	    N_TRSIZE(ex) || N_DRSIZE(ex) ||
-	    i_size_read(file_inode(bprm->file)) < ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
-		return -ENOEXEC;
-	}
-
-	/*
-	 * Requires a mmap handler. This prevents people from using a.out
-	 * as part of an exploit attack against /proc-related vulnerabilities.
-	 */
-	if (!bprm->file->f_op->mmap)
-		return -ENOEXEC;
-
-	fd_offset = N_TXTOFF(ex);
-
-	/* Check initial limits. This avoids letting people circumvent
-	 * size limits imposed on them by creating programs with large
-	 * arrays in the data or bss.
-	 */
-	rlim = rlimit(RLIMIT_DATA);
-	if (rlim >= RLIM_INFINITY)
-		rlim = ~0;
-	if (ex.a_data + ex.a_bss > rlim)
-		return -ENOMEM;
-
-	/* Flush all traces of the currently running executable */
-	retval = flush_old_exec(bprm);
-	if (retval)
-		return retval;
-
-	/* OK, This is the point of no return */
-#ifdef __alpha__
-	SET_AOUT_PERSONALITY(bprm, ex);
-#else
-	set_personality(PER_LINUX);
-#endif
-	setup_new_exec(bprm);
-
-	current->mm->end_code = ex.a_text +
-		(current->mm->start_code = N_TXTADDR(ex));
-	current->mm->end_data = ex.a_data +
-		(current->mm->start_data = N_DATADDR(ex));
-	current->mm->brk = ex.a_bss +
-		(current->mm->start_brk = N_BSSADDR(ex));
-
-	retval = setup_arg_pages(bprm, STACK_TOP, EXSTACK_DEFAULT);
-	if (retval < 0)
-		return retval;
-
-	install_exec_creds(bprm);
-
-	if (N_MAGIC(ex) == OMAGIC) {
-		unsigned long text_addr, map_size;
-		loff_t pos;
-
-		text_addr = N_TXTADDR(ex);
-
-#ifdef __alpha__
-		pos = fd_offset;
-		map_size = ex.a_text+ex.a_data + PAGE_SIZE - 1;
-#else
-		pos = 32;
-		map_size = ex.a_text+ex.a_data;
-#endif
-		error = vm_brk(text_addr & PAGE_MASK, map_size);
-		if (error)
-			return error;
-
-		error = read_code(bprm->file, text_addr, pos,
-				  ex.a_text+ex.a_data);
-		if ((signed long)error < 0)
-			return error;
-	} else {
-		if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
-		    (N_MAGIC(ex) != NMAGIC) && printk_ratelimit())
-		{
-			printk(KERN_NOTICE "executable not page aligned\n");
-		}
-
-		if ((fd_offset & ~PAGE_MASK) != 0 && printk_ratelimit())
-		{
-			printk(KERN_WARNING 
-			       "fd_offset is not page aligned. Please convert program: %pD\n",
-			       bprm->file);
-		}
-
-		if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) {
-			error = vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
-			if (error)
-				return error;
-
-			read_code(bprm->file, N_TXTADDR(ex), fd_offset,
-				  ex.a_text + ex.a_data);
-			goto beyond_if;
-		}
-
-		error = vm_mmap(bprm->file, N_TXTADDR(ex), ex.a_text,
-			PROT_READ | PROT_EXEC,
-			MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE | MAP_EXECUTABLE,
-			fd_offset);
-
-		if (error != N_TXTADDR(ex))
-			return error;
-
-		error = vm_mmap(bprm->file, N_DATADDR(ex), ex.a_data,
-				PROT_READ | PROT_WRITE | PROT_EXEC,
-				MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE | MAP_EXECUTABLE,
-				fd_offset + ex.a_text);
-		if (error != N_DATADDR(ex))
-			return error;
-	}
-beyond_if:
-	set_binfmt(&aout_format);
-
-	retval = set_brk(current->mm->start_brk, current->mm->brk);
-	if (retval < 0)
-		return retval;
-
-	current->mm->start_stack =
-		(unsigned long) create_aout_tables((char __user *) bprm->p, bprm);
-#ifdef __alpha__
-	regs->gp = ex.a_gpvalue;
-#endif
-	finalize_exec(bprm);
-	start_thread(regs, ex.a_entry, current->mm->start_stack);
-	return 0;
-}
-
-static int load_aout_library(struct file *file)
-{
-	struct inode * inode;
-	unsigned long bss, start_addr, len;
-	unsigned long error;
-	int retval;
-	struct exec ex;
-	loff_t pos = 0;
-
-	inode = file_inode(file);
-
-	retval = -ENOEXEC;
-	error = kernel_read(file, &ex, sizeof(ex), &pos);
-	if (error != sizeof(ex))
-		goto out;
-
-	/* We come in here for the regular a.out style of shared libraries */
-	if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
-	    N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
-	    i_size_read(inode) < ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
-		goto out;
-	}
-
-	/*
-	 * Requires a mmap handler. This prevents people from using a.out
-	 * as part of an exploit attack against /proc-related vulnerabilities.
-	 */
-	if (!file->f_op->mmap)
-		goto out;
-
-	if (N_FLAGS(ex))
-		goto out;
-
-	/* For  QMAGIC, the starting address is 0x20 into the page.  We mask
-	   this off to get the starting address for the page */
-
-	start_addr =  ex.a_entry & 0xfffff000;
-
-	if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
-		if (printk_ratelimit())
-		{
-			printk(KERN_WARNING 
-			       "N_TXTOFF is not page aligned. Please convert library: %pD\n",
-			       file);
-		}
-		retval = vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
-		if (retval)
-			goto out;
-
-		read_code(file, start_addr, N_TXTOFF(ex),
-			  ex.a_text + ex.a_data);
-		retval = 0;
-		goto out;
-	}
-	/* Now use mmap to map the library into memory. */
-	error = vm_mmap(file, start_addr, ex.a_text + ex.a_data,
-			PROT_READ | PROT_WRITE | PROT_EXEC,
-			MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE,
-			N_TXTOFF(ex));
-	retval = error;
-	if (error != start_addr)
-		goto out;
-
-	len = PAGE_ALIGN(ex.a_text + ex.a_data);
-	bss = ex.a_text + ex.a_data + ex.a_bss;
-	if (bss > len) {
-		retval = vm_brk(start_addr + len, bss - len);
-		if (retval)
-			goto out;
-	}
-	retval = 0;
-out:
-	return retval;
-}
-
-static int __init init_aout_binfmt(void)
-{
-	register_binfmt(&aout_format);
-	return 0;
-}
-
-static void __exit exit_aout_binfmt(void)
-{
-	unregister_binfmt(&aout_format);
-}
-
-core_initcall(init_aout_binfmt);
-module_exit(exit_aout_binfmt);
-MODULE_LICENSE("GPL");
diff --git a/include/linux/a.out.h b/include/linux/a.out.h
deleted file mode 100644
index 600cf45645c6..000000000000
--- a/include/linux/a.out.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __A_OUT_GNU_H__
-#define __A_OUT_GNU_H__
-
-#include <uapi/linux/a.out.h>
-
-#ifndef __ASSEMBLY__
-#ifdef linux
-#include <asm/page.h>
-#if defined(__i386__) || defined(__mc68000__)
-#else
-#ifndef SEGMENT_SIZE
-#define SEGMENT_SIZE	PAGE_SIZE
-#endif
-#endif
-#endif
-#endif /*__ASSEMBLY__ */
-#endif /* __A_OUT_GNU_H__ */

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-10 22:40                     ` Linus Torvalds
@ 2019-03-10 23:19                       ` Al Viro
  2019-03-11  7:20                       ` John Paul Adrian Glaubitz
                                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 42+ messages in thread
From: Al Viro @ 2019-03-10 23:19 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Sun, Mar 10, 2019 at 03:40:20PM -0700, Linus Torvalds wrote:
>  SYSCALL_DEFINE3(osf_readv, unsigned long, fd,
>  		const struct iovec __user *, vector, unsigned long, count)
>  {
> -#ifdef CONFIG_OSF4_COMPAT
> -	if (unlikely(personality(current->personality) == PER_OSF4))
> -		if (osf_fix_iov_len(vector, count))
> -			return -EFAULT;
> -#endif
> -
>  	return sys_readv(fd, vector, count);
>  }
>  
>  SYSCALL_DEFINE3(osf_writev, unsigned long, fd,
>  		const struct iovec __user *, vector, unsigned long, count)
>  {
> -#ifdef CONFIG_OSF4_COMPAT
> -	if (unlikely(personality(current->personality) == PER_OSF4))
> -		if (osf_fix_iov_len(vector, count))
> -			return -EFAULT;
> -#endif
>  	return sys_writev(fd, vector, count);
>  }

Might as well kill those two off, while we are at it - just use sys_readv/sys_writev
in arch/alpha/kernel/syscalls/syscall.tbl and be done with that...

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-10 22:40                     ` Linus Torvalds
  2019-03-10 23:19                       ` Al Viro
@ 2019-03-11  7:20                       ` John Paul Adrian Glaubitz
  2019-03-11 11:02                       ` Arnd Bergmann
  2019-03-11 16:26                       ` Måns Rullgård
  3 siblings, 0 replies; 42+ messages in thread
From: John Paul Adrian Glaubitz @ 2019-03-11  7:20 UTC (permalink / raw)
  To: Linus Torvalds, Matt Turner
  Cc: Borislav Petkov, Alan Cox, Matthew Wilcox, Jann Horn, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k,
	Michael Cree

Hi Linus!

On 3/11/19 7:40 AM, Linus Torvalds wrote:
> So this attached patch does not compile on alpha, but it's been many
> many years since I had an alpha to test with, so I'm stuck.

Michael Cree (CC'ed) has several Alpha servers running which are also used
for building Debian packages and testing kernels.

I also have four AlphaStations (233, 433au and XP-1000) on which I could
test any patch. But I'm currently in Japan until Friday next week, so
I don't have any means to access the machines.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-10 22:40                     ` Linus Torvalds
  2019-03-10 23:19                       ` Al Viro
  2019-03-11  7:20                       ` John Paul Adrian Glaubitz
@ 2019-03-11 11:02                       ` Arnd Bergmann
  2019-03-11 16:26                       ` Måns Rullgård
  3 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2019-03-11 11:02 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Sun, Mar 10, 2019 at 11:46 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <mattst88@gmail.com> wrote:
> >
> > I'm not aware of a reason to keep a.out support on alpha.
>
> Hmm. I was looking at removing a.out support entirely, but it's
> actually fairly incestuous on alpha.
>
> For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
> support in it. Maybe it can just be removed entirely.
>
> There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c.
>
> Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense
> without a.out support.
>
> So this attached patch does not compile on alpha, but it's been many
> many years since I had an alpha to test with, so I'm stuck.
>
> Matt, can you fill in the details and complete this patch?

I wonder if we could remove the osf time32 compat code as well,
this was one of the areas that kept causing problems with the y2038
rework. (I think it's all good now, but it's never been tested as far as I
can tell).

For some syscalls (e.g. brk, mmap, getxuid, ...) we definitely need to
keep the osf1 version, since it is the only supported ABI.

I just looked up some really old source trees and found that glibc-2.1
was the first release to use 64-bit time_t the way we do it today,
as implemented in [1], so all Debian and SuSE releases for alpha
had it, but any ELF binaries built on Red Hat Linux 4.x and 5.x
(released 1996 through 1998) or earlier would use 32-bit time_t
osf1 syscalls. Red Hat 2.x and 3.x were a.out based on alpha.

      Arnd

[1] https://repo.or.cz/glibc/history.git/commitdiff/64819b5c3a94e81e4

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-10 22:40                     ` Linus Torvalds
                                         ` (2 preceding siblings ...)
  2019-03-11 11:02                       ` Arnd Bergmann
@ 2019-03-11 16:26                       ` Måns Rullgård
  2019-03-11 16:45                         ` Linus Torvalds
  2019-03-11 18:58                         ` Matt Turner
  3 siblings, 2 replies; 42+ messages in thread
From: Måns Rullgård @ 2019-03-11 16:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <mattst88@gmail.com> wrote:
>>
>> I'm not aware of a reason to keep a.out support on alpha.
>
> Hmm. I was looking at removing a.out support entirely, but it's
> actually fairly incestuous on alpha.
>
> For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
> support in it. Maybe it can just be removed entirely.
>
> There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c.
>
> Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense
> without a.out support.

Anyone running an Alpha machine likely also has some old OSF/1 binaries
they may wish to use.  It would be a shame to remove this feature, IMO.

-- 
Måns Rullgård

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 16:26                       ` Måns Rullgård
@ 2019-03-11 16:45                         ` Linus Torvalds
  2019-03-11 18:08                           ` Måns Rullgård
  2019-03-11 18:58                         ` Matt Turner
  1 sibling, 1 reply; 42+ messages in thread
From: Linus Torvalds @ 2019-03-11 16:45 UTC (permalink / raw)
  To: Måns Rullgård
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård <mans@mansr.com> wrote:
>
> Anyone running an Alpha machine likely also has some old OSF/1 binaries
> they may wish to use.  It would be a shame to remove this feature, IMO.

If that's the case then we'd have to keep a.out alive for alpha, since
that's the OSF/1 binary format (at least the only one we support - I'm
not sure if later versions of OSF/1 ended up getting ELF).

Which I guess we could do, but the question is whether people really
do have OSF/1 binaries. It was really useful early on as a source of
known-good binaries to test with, but I'm not convinced it's still in
use.

It's not like there were OSF/1 binaries that we didn't havce access to
natively (well, there _were_ special ones that didn't have open source
versions, but most of them required more system-side support than
Linux ever implemented, afaik).

                           Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 16:45                         ` Linus Torvalds
@ 2019-03-11 18:08                           ` Måns Rullgård
  2019-03-11 19:03                             ` Linus Torvalds
  0 siblings, 1 reply; 42+ messages in thread
From: Måns Rullgård @ 2019-03-11 18:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård <mans@mansr.com> wrote:
>>
>> Anyone running an Alpha machine likely also has some old OSF/1 binaries
>> they may wish to use.  It would be a shame to remove this feature, IMO.
>
> If that's the case then we'd have to keep a.out alive for alpha, since
> that's the OSF/1 binary format (at least the only one we support - I'm
> not sure if later versions of OSF/1 ended up getting ELF).

The latest version I have is 5.1, and that uses ECOFF.

> Which I guess we could do, but the question is whether people really
> do have OSF/1 binaries. It was really useful early on as a source of
> known-good binaries to test with, but I'm not convinced it's still in
> use.
>
> It's not like there were OSF/1 binaries that we didn't havce access to
> natively (well, there _were_ special ones that didn't have open source
> versions, but most of them required more system-side support than
> Linux ever implemented, afaik).

I don't have any specific examples, but I can well imagine people
keeping an Alpha machine for no other reason than the ability to run
some (old) application only available (to them) for OSF/1.  Running them
on Linux rather than Tru64 brings the advantage of being a modern system
in other regards.

For anything open source, there's little reason to keep the Alpha at
all.

-- 
Måns Rullgård

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 16:26                       ` Måns Rullgård
  2019-03-11 16:45                         ` Linus Torvalds
@ 2019-03-11 18:58                         ` Matt Turner
  1 sibling, 0 replies; 42+ messages in thread
From: Matt Turner @ 2019-03-11 18:58 UTC (permalink / raw)
  To: Måns Rullgård
  Cc: Linus Torvalds, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård <mans@mansr.com> wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <mattst88@gmail.com> wrote:
> >>
> >> I'm not aware of a reason to keep a.out support on alpha.
> >
> > Hmm. I was looking at removing a.out support entirely, but it's
> > actually fairly incestuous on alpha.
> >
> > For example, arch/alpha/boot/tools/objstrip.c very much has some a.out
> > support in it. Maybe it can just be removed entirely.
> >
> > There's also an a.out.h include in arch/alpha/kernel/binfmt_loader.c.
> >
> > Finally, note that CONFIG_OSF4_COMPAT also no longer makes sense
> > without a.out support.
>
> Anyone running an Alpha machine likely also has some old OSF/1 binaries
> they may wish to use.  It would be a shame to remove this feature, IMO.

Tru64 5.1 uses ECOFF binaries, I believe. Do you know when OSF/1 /
Digital UNIX / Tru64 switched from a.out to ECOFF?

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 18:08                           ` Måns Rullgård
@ 2019-03-11 19:03                             ` Linus Torvalds
  2019-03-11 19:47                               ` Måns Rullgård
  2019-04-16  3:19                               ` Jon Masters
  0 siblings, 2 replies; 42+ messages in thread
From: Linus Torvalds @ 2019-03-11 19:03 UTC (permalink / raw)
  To: Måns Rullgård
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
>
> The latest version I have is 5.1, and that uses ECOFF.

ECOFF _is_ a.out as far as Linux is concerned.

So Linux basically treats ECOFF as "regular a.out with just some
header extensions".

We don't have any specific support for ECOFF.

I _think_. Again, it's been years and years.

               Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 19:03                             ` Linus Torvalds
@ 2019-03-11 19:47                               ` Måns Rullgård
  2019-03-11 20:50                                 ` Matt Turner
  2019-03-11 21:34                                 ` Arnd Bergmann
  2019-04-16  3:19                               ` Jon Masters
  1 sibling, 2 replies; 42+ messages in thread
From: Måns Rullgård @ 2019-03-11 19:47 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
>>
>> The latest version I have is 5.1, and that uses ECOFF.
>
> ECOFF _is_ a.out as far as Linux is concerned.
>
> So Linux basically treats ECOFF as "regular a.out with just some
> header extensions".
>
> We don't have any specific support for ECOFF.
>
> I _think_. Again, it's been years and years.

Right, which is why killing a.out entirely would have the unfortunate
effect of also removing the OSF/1 compatibility on Alpha.

If we are to support Alpha as an architecture at all, it makes sense to
support the things people actually use it for.

Now, personally I can live without it.  I just don't like to see
features removed without due consideration.

-- 
Måns Rullgård

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 19:47                               ` Måns Rullgård
@ 2019-03-11 20:50                                 ` Matt Turner
  2019-03-11 21:34                                 ` Arnd Bergmann
  1 sibling, 0 replies; 42+ messages in thread
From: Matt Turner @ 2019-03-11 20:50 UTC (permalink / raw)
  To: Måns Rullgård
  Cc: Linus Torvalds, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Mon, Mar 11, 2019 at 12:47 PM Måns Rullgård <mans@mansr.com> wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
> >>
> >> The latest version I have is 5.1, and that uses ECOFF.
> >
> > ECOFF _is_ a.out as far as Linux is concerned.
> >
> > So Linux basically treats ECOFF as "regular a.out with just some
> > header extensions".
> >
> > We don't have any specific support for ECOFF.
> >
> > I _think_. Again, it's been years and years.
>
> Right, which is why killing a.out entirely would have the unfortunate
> effect of also removing the OSF/1 compatibility on Alpha.
>
> If we are to support Alpha as an architecture at all, it makes sense to
> support the things people actually use it for.

I agree. I was not aware that a.out was effectively the same as ECOFF.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 19:47                               ` Måns Rullgård
  2019-03-11 20:50                                 ` Matt Turner
@ 2019-03-11 21:34                                 ` Arnd Bergmann
  2019-03-11 21:45                                   ` Linus Torvalds
                                                     ` (2 more replies)
  1 sibling, 3 replies; 42+ messages in thread
From: Arnd Bergmann @ 2019-03-11 21:34 UTC (permalink / raw)
  To: Måns Rullgård
  Cc: Linus Torvalds, Matt Turner, Borislav Petkov, Alan Cox,
	Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner, kernel list,
	linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov, linux-alpha,
	linux-m68k

On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård <mans@mansr.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
> >>
> >> The latest version I have is 5.1, and that uses ECOFF.
> >
> > ECOFF _is_ a.out as far as Linux is concerned.
> >
> > So Linux basically treats ECOFF as "regular a.out with just some
> > header extensions".
> >
> > We don't have any specific support for ECOFF.
> >
> > I _think_. Again, it's been years and years.
>
> Right, which is why killing a.out entirely would have the unfortunate
> effect of also removing the OSF/1 compatibility on Alpha.
>
> If we are to support Alpha as an architecture at all, it makes sense to
> support the things people actually use it for.
>
> Now, personally I can live without it.  I just don't like to see
> features removed without due consideration.

The main historic use case I've heard of was running Netscape
Navigator on Alpha Linux, before there was an open source version.
Doing this today to connect to the open internet is probably
a bit pointless, but there may be other use cases.

Looking at the system call table in the kernel
(arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a
specific subset that was required for a set of applications, and
not much more. Old system calls (osf_old_open, osf_execve,
osf_old_sigaction) are listed but not implemented, and the same
is true for most of the later calls (osf_fuser, osf_sigsendset,
osf_waitid, osf_signal, ...), just the ones in the middle are there.
This would also indicate that it never really worked as a
general-purpose emulation layer but was only there for a specific
set of applications.

Another data point I have is that osf1 emulation was broken
between linux-4.13 and linux-4.16 without anyone noticing, see
47669fb6b595 ("alpha: osf_sys.c: fix put_tv32 regression").

      Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 21:34                                 ` Arnd Bergmann
@ 2019-03-11 21:45                                   ` Linus Torvalds
  2019-03-11 22:12                                     ` Måns Rullgård
  2019-03-12  8:44                                     ` Geert Uytterhoeven
  2019-03-11 22:06                                   ` Måns Rullgård
  2019-03-11 22:11                                   ` Matt Turner
  2 siblings, 2 replies; 42+ messages in thread
From: Linus Torvalds @ 2019-03-11 21:45 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Måns Rullgård, Matt Turner, Borislav Petkov, Alan Cox,
	Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner, kernel list,
	linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov, linux-alpha,
	linux-m68k

On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> The main historic use case I've heard of was running Netscape
> Navigator on Alpha Linux, before there was an open source version.
> Doing this today to connect to the open internet is probably
> a bit pointless, but there may be other use cases.

The _really_ main version was that I decided to make my life easier
for the initial alpha port by trying to run basic (tested) OSF/1
binaries directly.

Netscape may have been one of the binaries people actually ended up
using, but it's probably not a reason any more, since the internet has
moved past that anyway.

> Looking at the system call table in the kernel
> (arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a
> specific subset that was required for a set of applications, and
> not much more.

Yeah, it never supported arbitrary binaries, particularly since
there's often lots of other issues too with running things like that
(ie filesystem layout etc). It worked for normal fairly well behaved
stuff, but wasn't ever a full OSF/1 emulation environment.

I _suspect_ nobody actually runs any OSF/1 binaries any more, but it
would obviously be good to verify that. Your argument that timeval
handling was broken _may_ be an indication of that (or may just mean
very few apps care).

I think we should try the a.out removal and see if anybody notices.

                    Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 21:34                                 ` Arnd Bergmann
  2019-03-11 21:45                                   ` Linus Torvalds
@ 2019-03-11 22:06                                   ` Måns Rullgård
  2019-03-11 22:11                                   ` Matt Turner
  2 siblings, 0 replies; 42+ messages in thread
From: Måns Rullgård @ 2019-03-11 22:06 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Linus Torvalds, Matt Turner, Borislav Petkov, Alan Cox,
	Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner, kernel list,
	linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov, linux-alpha,
	linux-m68k

Arnd Bergmann <arnd@arndb.de> writes:

> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård <mans@mansr.com> wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
>> >>
>> >> The latest version I have is 5.1, and that uses ECOFF.
>> >
>> > ECOFF _is_ a.out as far as Linux is concerned.
>> >
>> > So Linux basically treats ECOFF as "regular a.out with just some
>> > header extensions".
>> >
>> > We don't have any specific support for ECOFF.
>> >
>> > I _think_. Again, it's been years and years.
>>
>> Right, which is why killing a.out entirely would have the unfortunate
>> effect of also removing the OSF/1 compatibility on Alpha.
>>
>> If we are to support Alpha as an architecture at all, it makes sense to
>> support the things people actually use it for.
>>
>> Now, personally I can live without it.  I just don't like to see
>> features removed without due consideration.
>
> The main historic use case I've heard of was running Netscape
> Navigator on Alpha Linux, before there was an open source version.
> Doing this today to connect to the open internet is probably
> a bit pointless, but there may be other use cases.

Once upon a time, I used it to run Matlab.

> Looking at the system call table in the kernel
> (arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a
> specific subset that was required for a set of applications, and
> not much more. Old system calls (osf_old_open, osf_execve,
> osf_old_sigaction) are listed but not implemented, and the same
> is true for most of the later calls (osf_fuser, osf_sigsendset,
> osf_waitid, osf_signal, ...), just the ones in the middle are there.
> This would also indicate that it never really worked as a
> general-purpose emulation layer but was only there for a specific
> set of applications.

It works for many applications, though I did have to add a few syscalls
myself (yes, I sent patches).

> Another data point I have is that osf1 emulation was broken
> between linux-4.13 and linux-4.16 without anyone noticing, see
> 47669fb6b595 ("alpha: osf_sys.c: fix put_tv32 regression").

That's interesting, but it doesn't mean nobody is using it.  I tend to
run the LTS branches and switch to a new one only once it seems to have
settled a bit, so when 4.16 was released, I was probably still running
4.9.  I don't think I'm the only one using this strategy.

-- 
Måns Rullgård

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 21:34                                 ` Arnd Bergmann
  2019-03-11 21:45                                   ` Linus Torvalds
  2019-03-11 22:06                                   ` Måns Rullgård
@ 2019-03-11 22:11                                   ` Matt Turner
  2019-03-12  6:38                                     ` Michael Cree
  2 siblings, 1 reply; 42+ messages in thread
From: Matt Turner @ 2019-03-11 22:11 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Måns Rullgård, Linus Torvalds, Borislav Petkov,
	Alan Cox, Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner,
	kernel list, linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov, linux-alpha,
	linux-m68k

On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård <mans@mansr.com> wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
> > >>
> > >> The latest version I have is 5.1, and that uses ECOFF.
> > >
> > > ECOFF _is_ a.out as far as Linux is concerned.
> > >
> > > So Linux basically treats ECOFF as "regular a.out with just some
> > > header extensions".
> > >
> > > We don't have any specific support for ECOFF.
> > >
> > > I _think_. Again, it's been years and years.
> >
> > Right, which is why killing a.out entirely would have the unfortunate
> > effect of also removing the OSF/1 compatibility on Alpha.
> >
> > If we are to support Alpha as an architecture at all, it makes sense to
> > support the things people actually use it for.
> >
> > Now, personally I can live without it.  I just don't like to see
> > features removed without due consideration.
>
> The main historic use case I've heard of was running Netscape
> Navigator on Alpha Linux, before there was an open source version.
> Doing this today to connect to the open internet is probably
> a bit pointless, but there may be other use cases.

The best use case I know of is to run their C compiler. Måns sent
patches in fact to make it work.

There is a Linux version of the same compiler but I have a vague
memory that it's broken in various ways that the Tru64 version is not.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 21:45                                   ` Linus Torvalds
@ 2019-03-11 22:12                                     ` Måns Rullgård
  2019-03-12  8:44                                     ` Geert Uytterhoeven
  1 sibling, 0 replies; 42+ messages in thread
From: Måns Rullgård @ 2019-03-11 22:12 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Arnd Bergmann, Matt Turner, Borislav Petkov, Alan Cox,
	Matthew Wilcox, Jann Horn, Al Viro, Thomas Gleixner, kernel list,
	linux-fsdevel, the arch/x86 maintainers, Linux API,
	Andrew Morton, Richard Weinberger, Anton Ivanov, linux-alpha,
	linux-m68k

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> The main historic use case I've heard of was running Netscape
>> Navigator on Alpha Linux, before there was an open source version.
>> Doing this today to connect to the open internet is probably
>> a bit pointless, but there may be other use cases.
>
> The _really_ main version was that I decided to make my life easier
> for the initial alpha port by trying to run basic (tested) OSF/1
> binaries directly.
>
> Netscape may have been one of the binaries people actually ended up
> using, but it's probably not a reason any more, since the internet has
> moved past that anyway.
>
>> Looking at the system call table in the kernel
>> (arch/alpha/kernel/syscalls/syscall.tbl), we seem to support a
>> specific subset that was required for a set of applications, and
>> not much more.
>
> Yeah, it never supported arbitrary binaries, particularly since
> there's often lots of other issues too with running things like that
> (ie filesystem layout etc). It worked for normal fairly well behaved
> stuff, but wasn't ever a full OSF/1 emulation environment.
>
> I _suspect_ nobody actually runs any OSF/1 binaries any more, but it
> would obviously be good to verify that. Your argument that timeval
> handling was broken _may_ be an indication of that (or may just mean
> very few apps care).

Does it count if I fire up an Alpha and run a few OSF/1 binaries right
now? :-)

-- 
Måns Rullgård

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 22:11                                   ` Matt Turner
@ 2019-03-12  6:38                                     ` Michael Cree
  0 siblings, 0 replies; 42+ messages in thread
From: Michael Cree @ 2019-03-12  6:38 UTC (permalink / raw)
  To: Matt Turner
  Cc: Arnd Bergmann, Måns Rullgård, Linus Torvalds,
	Borislav Petkov, Alan Cox, Matthew Wilcox, Jann Horn, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Mon, Mar 11, 2019 at 03:11:55PM -0700, Matt Turner wrote:
> On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård <mans@mansr.com> wrote:
> > > Linus Torvalds <torvalds@linux-foundation.org> writes:
> > > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
> > > > We don't have any specific support for ECOFF.
> > > >
> > > > I _think_. Again, it's been years and years.

I agree. I personally have never run any OSF/1 executables on
Linux Alpha and have no interest in doing so.

> > The main historic use case I've heard of was running Netscape
> > Navigator on Alpha Linux, before there was an open source version.
> > Doing this today to connect to the open internet is probably
> > a bit pointless, but there may be other use cases.
> 
> The best use case I know of is to run their C compiler. Måns sent
> patches in fact to make it work.
> 
> There is a Linux version of the same compiler but I have a vague
> memory that it's broken in various ways that the Tru64 version is
> not.

The last time I tried the Compaq C compiler for Alpha-Linux it still
worked, well, that is, the compiler worked, but the library header
files are broken and haven't worked with glibc for a long time.  So
it is only useful as a free-standing compiler.

In the past it also produced better code than gcc, but gcc is now
so vastly improved w.r.t. optimisation and compliance to more recent
standards, that I would be surprised if there is any real use for
the Compaq compiler.

Cheers,
Michael.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 21:45                                   ` Linus Torvalds
  2019-03-11 22:12                                     ` Måns Rullgård
@ 2019-03-12  8:44                                     ` Geert Uytterhoeven
  2019-03-14 18:38                                       ` Miguel Ojeda
  1 sibling, 1 reply; 42+ messages in thread
From: Geert Uytterhoeven @ 2019-03-12  8:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Arnd Bergmann, Måns Rullgård, Matt Turner,
	Borislav Petkov, Alan Cox, Matthew Wilcox, Jann Horn, Al Viro,
	Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Mon, Mar 11, 2019 at 10:46 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > The main historic use case I've heard of was running Netscape
> > Navigator on Alpha Linux, before there was an open source version.
> > Doing this today to connect to the open internet is probably
> > a bit pointless, but there may be other use cases.
>
> The _really_ main version was that I decided to make my life easier
> for the initial alpha port by trying to run basic (tested) OSF/1
> binaries directly.
>
> Netscape may have been one of the binaries people actually ended up
> using, but it's probably not a reason any more, since the internet has
> moved past that anyway.

Yeah, the alphas on the server side, powering AltaVista, are also long
gone...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-12  8:44                                     ` Geert Uytterhoeven
@ 2019-03-14 18:38                                       ` Miguel Ojeda
  0 siblings, 0 replies; 42+ messages in thread
From: Miguel Ojeda @ 2019-03-14 18:38 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linus Torvalds, Arnd Bergmann, Måns Rullgård,
	Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

On Tue, Mar 12, 2019 at 9:46 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Yeah, the alphas on the server side, powering AltaVista, are also long
> gone...

As usual with these things, people can still use older Linux releases
for a very long time. If they really need it (e.g. commercially), they
have the reference code and can bring it up to speed again relatively
easily. It is not as if they have no way to submit it back again.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH] x86: Deprecate a.out support
  2019-03-11 19:03                             ` Linus Torvalds
  2019-03-11 19:47                               ` Måns Rullgård
@ 2019-04-16  3:19                               ` Jon Masters
  1 sibling, 0 replies; 42+ messages in thread
From: Jon Masters @ 2019-04-16  3:19 UTC (permalink / raw)
  To: Linus Torvalds, Måns Rullgård
  Cc: Matt Turner, Borislav Petkov, Alan Cox, Matthew Wilcox,
	Jann Horn, Al Viro, Thomas Gleixner, kernel list, linux-fsdevel,
	the arch/x86 maintainers, Linux API, Andrew Morton,
	Richard Weinberger, Anton Ivanov, linux-alpha, linux-m68k

Hi Linus,

I'm Jon, and I just bought my first Alpha. What can I say, I was late to
the party, and I probably need to get out more. Actually, I wanted it
for its memory consistency model, or (some would say) lack thereof.

On 3/11/19 3:03 PM, Linus Torvalds wrote:
> On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <mans@mansr.com> wrote:
>>
>> The latest version I have is 5.1, and that uses ECOFF.
> 
> ECOFF _is_ a.out as far as Linux is concerned.
> 
> So Linux basically treats ECOFF as "regular a.out with just some
> header extensions".
> 
> We don't have any specific support for ECOFF.
> 
> I _think_. Again, it's been years and years.

...so removing a.out would break various boot tooling as well. I'm still
working on getting my Miata up and running upstream kernels (should be
shortly) but I'm happy to help out testing any proposals.

Jon.

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2019-04-16  3:20 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-01 23:57 a.out coredumping: fix or delete? Jann Horn
2019-03-03  1:09 ` Andy Lutomirski
2019-03-05  9:19 ` Borislav Petkov
2019-03-05 12:22   ` Matthew Wilcox
2019-03-05 13:43     ` Alan Cox
2019-03-05 14:59       ` [PATCH] x86: Deprecate a.out support Borislav Petkov
2019-03-05 15:17         ` Richard Weinberger
2019-03-05 16:22         ` Linus Torvalds
2019-03-05 16:30           ` Jann Horn
2019-03-05 17:32             ` Borislav Petkov
2019-03-05 17:31           ` Borislav Petkov
2019-03-05 17:58             ` Linus Torvalds
2019-03-05 18:11               ` Borislav Petkov
2019-03-05 18:18                 ` Borislav Petkov
2019-03-06 15:07                   ` Geert Uytterhoeven
2019-03-10 21:37                   ` Matt Turner
2019-03-10 22:40                     ` Linus Torvalds
2019-03-10 23:19                       ` Al Viro
2019-03-11  7:20                       ` John Paul Adrian Glaubitz
2019-03-11 11:02                       ` Arnd Bergmann
2019-03-11 16:26                       ` Måns Rullgård
2019-03-11 16:45                         ` Linus Torvalds
2019-03-11 18:08                           ` Måns Rullgård
2019-03-11 19:03                             ` Linus Torvalds
2019-03-11 19:47                               ` Måns Rullgård
2019-03-11 20:50                                 ` Matt Turner
2019-03-11 21:34                                 ` Arnd Bergmann
2019-03-11 21:45                                   ` Linus Torvalds
2019-03-11 22:12                                     ` Måns Rullgård
2019-03-12  8:44                                     ` Geert Uytterhoeven
2019-03-14 18:38                                       ` Miguel Ojeda
2019-03-11 22:06                                   ` Måns Rullgård
2019-03-11 22:11                                   ` Matt Turner
2019-03-12  6:38                                     ` Michael Cree
2019-04-16  3:19                               ` Jon Masters
2019-03-11 18:58                         ` Matt Turner
2019-03-06 16:55           ` Enrico Weigelt, metux IT consult
2019-03-06 17:52             ` [PATCH] fs: binfmt: mark aout as broken Enrico Weigelt, metux IT consult
2019-03-06 12:25     ` a.out coredumping: fix or delete? Thomas Gleixner
2019-03-06 14:11       ` Theodore Y. Ts'o
2019-03-06 16:52         ` Alan Cox
2019-03-06 17:45           ` Andy Lutomirski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).