LinuxLists.cc - a.out coredumping: fix or delete?

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

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.

2019-03-05 13:54:45

by Matthew Wilcox

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

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.

2019-03-05 14:25:42

by Alan Cox

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

> 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

2019-03-05 15:53:33

[permalink] [raw]

Subject: [PATCH] x86: Deprecate a.out support

+ 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 <[email protected]>
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 <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Anton Ivanov <[email protected]>
Cc: Jann Horn <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: lkml <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: <[email protected]>
---
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.

2019-03-05 15:55:01

by Richard Weinberger

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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 <[email protected]>
> 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 <[email protected]>
> Cc: Al Viro <[email protected]>
> Cc: Anton Ivanov <[email protected]>
> Cc: Jann Horn <[email protected]>
> Cc: <[email protected]>
> Cc: <[email protected]>
> Cc: lkml <[email protected]>
> Cc: Matthew Wilcox <[email protected]>
> Cc: Richard Weinberger <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: <[email protected]>
> ---
> 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 <[email protected]>

Thanks,
//richard

2019-03-05 17:34:06

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov <[email protected]> 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

Attachments:

patch.diff (8.31 kB)

2019-03-05 17:36:37

by Jann Horn

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Tue, Mar 5, 2019 at 5:22 PM Linus Torvalds
<[email protected]> wrote:
> On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov <[email protected]> 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?

2019-03-05 17:41:52

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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.

2019-03-05 17:43:04

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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.

2019-03-05 18:53:14

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Tue, Mar 5, 2019 at 9:31 AM Borislav Petkov <[email protected]> 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

2019-03-05 19:03:40

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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.

2019-03-05 19:04:56

by Enrico Weigelt, metux IT consult

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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.

2019-03-06 14:48:03

by Thomas Gleixner

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

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

2019-03-06 17:46:13

by Theodore Ts'o

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

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

2019-03-06 17:50:47

by Geert Uytterhoeven

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

Hi Borislav,

On Tue, Mar 5, 2019 at 8:04 PM Borislav Petkov <[email protected]> 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 -- [email protected]

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

2019-03-06 18:32:55

by Alan Cox

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

On Wed, 6 Mar 2019 09:11:44 -0500
"Theodore Y. Ts'o" <[email protected]> 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

2019-03-06 18:34:16

by Andy Lutomirski

[permalink] [raw]

Subject: Re: a.out coredumping: fix or delete?

On Wed, Mar 6, 2019 at 8:53 AM Alan Cox <[email protected]> wrote:
>
> On Wed, 6 Mar 2019 09:11:44 -0500
> "Theodore Y. Ts'o" <[email protected]> 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 :)

2019-03-06 18:35:59

[permalink] [raw]

Subject: [PATCH] fs: binfmt: mark aout as broken

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 <[email protected]>
---
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

2019-03-06 19:17:51

by Enrico Weigelt, metux IT consult

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On 05.03.19 17:22, Linus Torvalds wrote:
> On Tue, Mar 5, 2019 at 6:59 AM Borislav Petkov <[email protected]> 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
[email protected] -- +49-151-27565287

2019-03-10 21:40:22

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Tue, Mar 5, 2019 at 11:04 AM Borislav Petkov <[email protected]> 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.

2019-03-11 00:26:54

by Al Viro

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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

2019-03-11 00:44:58

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <[email protected]> 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

Attachments:

patch.diff (23.30 kB)

2019-03-11 07:21:42

by John Paul Adrian Glaubitz

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

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 - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2019-03-11 11:03:36

by Arnd Bergmann

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Sun, Mar 10, 2019 at 11:46 PM Linus Torvalds
<[email protected]> wrote:
>
> On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <[email protected]> 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

2019-03-11 16:27:56

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

Linus Torvalds <[email protected]> writes:

> On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <[email protected]> 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

2019-03-11 16:46:52

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård <[email protected]> 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

2019-03-11 18:09:04

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

Linus Torvalds <[email protected]> writes:

> On Mon, Mar 11, 2019 at 9:26 AM M?ns Rullg?rd <[email protected]> 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

2019-03-11 18:59:57

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 9:26 AM Måns Rullgård <[email protected]> wrote:
>
> Linus Torvalds <[email protected]> writes:
>
> > On Sun, Mar 10, 2019 at 2:37 PM Matt Turner <[email protected]> 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?

2019-03-11 19:11:20

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <[email protected]> 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

2019-03-11 19:49:56

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

Linus Torvalds <[email protected]> writes:

> On Mon, Mar 11, 2019 at 11:08 AM M?ns Rullg?rd <[email protected]> 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

2019-03-11 20:52:13

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 12:47 PM Måns Rullgård <[email protected]> wrote:
>
> Linus Torvalds <[email protected]> writes:
>
> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <[email protected]> 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.

2019-03-11 21:35:20

by Arnd Bergmann

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård <[email protected]> wrote:
> Linus Torvalds <[email protected]> writes:
> > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <[email protected]> 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

2019-03-11 21:54:09

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <[email protected]> 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

2019-03-11 22:07:36

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

Arnd Bergmann <[email protected]> writes:

> On Mon, Mar 11, 2019 at 8:47 PM M?ns Rullg?rd <[email protected]> wrote:
>> Linus Torvalds <[email protected]> writes:
>> > On Mon, Mar 11, 2019 at 11:08 AM M?ns Rullg?rd <[email protected]> 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

2019-03-11 22:13:12

[permalink] [raw]

Subject: Re: [PATCH] x86: Deprecate a.out support

On Mon, Mar 11, 2019 at 2:34 PM Arnd Bergmann <[email protected]> wrote:
>
> On Mon, Mar 11, 2019 at 8:47 PM Måns Rullgård <[email protected]> wrote:
> > Linus Torvalds <[email protected]> writes:
> > > On Mon, Mar 11, 2019 at 11:08 AM Måns Rullgård <[email protected]> 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.

2019-03-11 22:15:02