4 ms·

This is (apparently, looking at the patch; maybe there's something I am missing that is outside the scope of this one patch) such a ridiculously small amount of

by saurik 4y ago

This is (apparently, looking at the patch; maybe there's something I am missing that is outside the scope of this one patch) such a ridiculously small amount of sufficiently trivial code that this doesn't really feel at all like a "win" to me if there is even a single person out there with an a.out binary.

dale_glass 4y ago
It seems worthwhile to me from the point of view of not keeping ancient junk around that almost nobody remembers exists anymore. It could have some security bug, or it may complicate future work because changes break something in `binfmt_aout.c`, and then somebody has to figure out how to fix it and how to test that fix, which is probably a waste of time.
- lokedhs 4y ago
  It would be possible to maintain this as a lodable module out of tree if needed, so even me, who's all in favour of keeping all the old stuff, can agree that it makes sense to not have it in the kernel.
  - dale_glass 4y ago
    Having it as a loadable module means it still has to compile, which means it adds a cost to maintenance work. The cost of obscure functionality can be extremely high. Say your change made this bit stop compiling. Now you might manage to fix the compile error, but how do you know it still works properly? Now you need to figure out how to test it. A formerly simple change can suddenly balloon into seeking out the 5 people in the world who still want this, and making sure they're happy.
    - lokedhs 4y ago
      What I meant was that the people who still want it can maintain it. Or at least fund someone to do the maintenance. The point was that just because it's removed from the kernel doesn't mean it has to disappear if there is still interest to keep it up to date.
      - dale_glass 4y ago
        Ok, but seems like an odd one to care about. The ELF transition was almost 30 years ago. Most anything earlier than that is in the garbage dump or a museum, and the software runs in a VM.
        lokedhs 4y ago
        Oh I don't really care about it other than from a nostalgia point of view. I started using Linux at 0.99 or so. I don't think I've used anything but ELF since it was introduced. And recent developments have shown that ELF is not a barrier to getting old binaries working (the recent port of Word Perfect for Unix).
    - Annatar 4y ago
  - tssva 4y ago
    ipx and ncpfs are examples of this. They were removed in 4.18 but have been maintained outside of the kernel. I use the ipx loadable module on a couple of systems running recent kernel versions.
- nraynaud 4y ago
  I was a bit dumbfounded by the article because I forgot that a.out is a format before being a filename.
  - lokedhs 4y ago
    I'm pretty sure it started out as a file name, it being the default output name of the C compiler in Unix. It didn't become the name of a format until Linux, and I think it really didn't get that name until ELF was introduced in Linux since they needed a way to distinguish the two formats.
    - nineteen999 4y ago
      From Wikipedia (and I've always understood this to be true): > This is an abbreviated form of "assembler output", the filename of the output of Ken Thompson's PDP-7 assembler https://en.wikipedia.org/wiki/A.out https://en.wikipedia.org/wiki/A.out
londons_explore 4y ago
This is the kind of code/feature that gets removed if anyone ever needs to edit it, for example because some of the API's it calls changes. I assume the patch writer is planning on making changes to those API's
mike_d 4y ago
Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. Support for a compression format specific to fax machines was used by a government to hack the cell phones of activists. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
- fegu 4y ago
  That article was today's most fascinating read for me. Thanks!
- KennyBlanken 4y ago
  Should be noted that a)virtually nobody used the compression method in question and b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters. That compression format should have been aggressively removed once the flaws were uncovered. It presented a real-life danger on so many fronts. Imagine engineering documents, medication orders, architectural specs, you name it. That compression algorithm easily could have killed people.
  - misnome 4y ago
    From what I remember from the kerfuffle around JBIG a few years ago, it was specifically a single manufacturers bad implementation that regularly swapped numbers. I believe that correct implementations weren't found to exhibit this problem except on symbols that were hard to read already?
    - mrguyorama 4y ago
      The problem was that JBIG had multiple different option sets, including an option that was explicitly "lossy" which here means that it is apt to replace one portion of an image with another. For some unfathomable reason, Xerox set this option as the default on many of their products, instead of the lossless, nearly as well compressing option.
  - 4y ago
orra 4y ago
Ten or fifteen years ago, I remember trying to run a demo version of Maple V. This version of the app, maybe from 1995, was old enough to be in a.out format. Unfortunately I struggled to run it, because libc was in ELF format, not a.out. Still, you have a point, the kernel code is not that much because the format is so simple. Arguably removing the code fails Linux's philosophy of not breaking userspace code.
- samus 4y ago
  Not wanting to break anybodys uses is exactly why this took so long. If there are no users anymore, maintaining support is as unnecessary as supporting the proprietary format in my head that I invented five seconds ago.
kleiba 4y ago
You might be interested in this LWN article on the topic: https://lwn.net/Articles/888741/ https://lwn.net/Articles/888741/ Excerpt: -- Kees Cook did do a little research on, seemingly, the only distribution that still supports Alpha (Gentoo) and found that the only ECOFF files present contained firmware, which does not run on the CPU anyway. He concluded that there would be no harm from removing a.out support on this platform: ""Let's do it"". It seems to be a universal rule that somebody always has to come along to ruin the party. In this case, just as it seemed like there were no further obstacles to the removal of a.out, James Jones showed up to let it be known that he was still using a.out: The use case is running an old set of tools to build programs for the Atari Jaguar. Namely, Atari's assembler (mac) and linker (aln). The alternative is running windows versions in dosbox, or using some replacements that have been developed based on an even older, less-featureful version of the source code for mac and aln, but which still haven't managed to add back in all the features needed to build some programs or use the Atari debugging tools (Also available in a.out only)." -- And here the HN discussion on said article: https://news.ycombinator.com/item?id=30792059 https://news.ycombinator.com/item?id=30792059
- KennyBlanken 4y ago
  I'm sure James Jones is perfectly capable of running a LTS kernel that still has support for a.out. He's working on decades old platforms...this really shouldn't phase him.
  - salawat 4y ago
    See, that attitude, right there is why Linus has historically needed to be a dick. Don't break the user and sanctimoniously pretend you're doing everyone else a favor.
  - benj111 4y ago
    It's faze btw.
- mid-kid 4y ago
  I wonder if those programs wouldn't be easy enough to convert into ELF. From cursory reading, it doesn't look like the format contains anything that wouldn't be able to be represented in an ELF file. Am I missing something?
Arnt 4y ago
IIRC the current code is enough to run some things, but not to work to spec, and that's how it was discovered. I have the impression that it's being killed mostly because the necessary maintenance effort is unjustified. Some people talk about hygiene and killing old cruft, but AFAICT that's just an additional reason. It's not much code now, but the current state is untenable. It needs effort or removal.

by saurik 4y ago

dale_glass 4y ago

It seems worthwhile to me from the point of view of not keeping ancient junk around that almost nobody remembers exists anymore. It could have some security bug, or it may complicate future work because changes break something in `binfmt_aout.c`, and then somebody has to figure out how to fix it and how to test that fix, which is probably a waste of time.

lokedhs 4y ago
It would be possible to maintain this as a lodable module out of tree if needed, so even me, who's all in favour of keeping all the old stuff, can agree that it makes sense to not have it in the kernel.
- dale_glass 4y ago
  Having it as a loadable module means it still has to compile, which means it adds a cost to maintenance work. The cost of obscure functionality can be extremely high. Say your change made this bit stop compiling. Now you might manage to fix the compile error, but how do you know it still works properly? Now you need to figure out how to test it. A formerly simple change can suddenly balloon into seeking out the 5 people in the world who still want this, and making sure they're happy.
  - lokedhs 4y ago
    What I meant was that the people who still want it can maintain it. Or at least fund someone to do the maintenance. The point was that just because it's removed from the kernel doesn't mean it has to disappear if there is still interest to keep it up to date.
    - dale_glass 4y ago
      Ok, but seems like an odd one to care about. The ELF transition was almost 30 years ago. Most anything earlier than that is in the garbage dump or a museum, and the software runs in a VM.
      - lokedhs 4y ago
        Oh I don't really care about it other than from a nostalgia point of view. I started using Linux at 0.99 or so. I don't think I've used anything but ELF since it was introduced. And recent developments have shown that ELF is not a barrier to getting old binaries working (the recent port of Word Perfect for Unix).
  - Annatar 4y ago
- tssva 4y ago
  ipx and ncpfs are examples of this. They were removed in 4.18 but have been maintained outside of the kernel. I use the ipx loadable module on a couple of systems running recent kernel versions.
nraynaud 4y ago
I was a bit dumbfounded by the article because I forgot that a.out is a format before being a filename.
- lokedhs 4y ago
  I'm pretty sure it started out as a file name, it being the default output name of the C compiler in Unix. It didn't become the name of a format until Linux, and I think it really didn't get that name until ELF was introduced in Linux since they needed a way to distinguish the two formats.
  - nineteen999 4y ago
    From Wikipedia (and I've always understood this to be true): > This is an abbreviated form of "assembler output", the filename of the output of Ken Thompson's PDP-7 assembler https://en.wikipedia.org/wiki/A.out https://en.wikipedia.org/wiki/A.out

londons_explore 4y ago

This is the kind of code/feature that gets removed if anyone ever needs to edit it, for example because some of the API's it calls changes. I assume the patch writer is planning on making changes to those API's

mike_d 4y ago

Last year we had a great public example of why eliminating attack surface should always be prioritized over legacy support. Support for a compression format specific to fax machines was used by a government to hack the cell phones of activists. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

fegu 4y ago
That article was today's most fascinating read for me. Thanks!
KennyBlanken 4y ago
Should be noted that a)virtually nobody used the compression method in question and b)in the few examples they did, it was quickly found to be harmful, modifying digits and letters. That compression format should have been aggressively removed once the flaws were uncovered. It presented a real-life danger on so many fronts. Imagine engineering documents, medication orders, architectural specs, you name it. That compression algorithm easily could have killed people.
- misnome 4y ago
  From what I remember from the kerfuffle around JBIG a few years ago, it was specifically a single manufacturers bad implementation that regularly swapped numbers. I believe that correct implementations weren't found to exhibit this problem except on symbols that were hard to read already?
  - mrguyorama 4y ago
    The problem was that JBIG had multiple different option sets, including an option that was explicitly "lossy" which here means that it is apt to replace one portion of an image with another. For some unfathomable reason, Xerox set this option as the default on many of their products, instead of the lossless, nearly as well compressing option.
- 4y ago

orra 4y ago

Ten or fifteen years ago, I remember trying to run a demo version of Maple V. This version of the app, maybe from 1995, was old enough to be in a.out format. Unfortunately I struggled to run it, because libc was in ELF format, not a.out. Still, you have a point, the kernel code is not that much because the format is so simple. Arguably removing the code fails Linux's philosophy of not breaking userspace code.

samus 4y ago
Not wanting to break anybodys uses is exactly why this took so long. If there are no users anymore, maintaining support is as unnecessary as supporting the proprietary format in my head that I invented five seconds ago.

kleiba 4y ago

You might be interested in this LWN article on the topic: https://lwn.net/Articles/888741/ https://lwn.net/Articles/888741/ Excerpt: -- Kees Cook did do a little research on, seemingly, the only distribution that still supports Alpha (Gentoo) and found that the only ECOFF files present contained firmware, which does not run on the CPU anyway. He concluded that there would be no harm from removing a.out support on this platform: ""Let's do it"". It seems to be a universal rule that somebody always has to come along to ruin the party. In this case, just as it seemed like there were no further obstacles to the removal of a.out, James Jones showed up to let it be known that he was still using a.out: The use case is running an old set of tools to build programs for the Atari Jaguar. Namely, Atari's assembler (mac) and linker (aln). The alternative is running windows versions in dosbox, or using some replacements that have been developed based on an even older, less-featureful version of the source code for mac and aln, but which still haven't managed to add back in all the features needed to build some programs or use the Atari debugging tools (Also available in a.out only)." -- And here the HN discussion on said article: https://news.ycombinator.com/item?id=30792059 https://news.ycombinator.com/item?id=30792059

KennyBlanken 4y ago
I'm sure James Jones is perfectly capable of running a LTS kernel that still has support for a.out. He's working on decades old platforms...this really shouldn't phase him.
- salawat 4y ago
  See, that attitude, right there is why Linus has historically needed to be a dick. Don't break the user and sanctimoniously pretend you're doing everyone else a favor.
- benj111 4y ago
  It's faze btw.
mid-kid 4y ago
I wonder if those programs wouldn't be easy enough to convert into ELF. From cursory reading, it doesn't look like the format contains anything that wouldn't be able to be represented in an ELF file. Am I missing something?

Arnt 4y ago

IIRC the current code is enough to run some things, but not to work to spec, and that's how it was discovered. I have the impression that it's being killed mostly because the necessary maintenance effort is unjustified. Some people talk about hygiene and killing old cruft, but AFAICT that's just an additional reason. It's not much code now, but the current state is untenable. It needs effort or removal.