Remove v850 from linux/elf-em.h
PATCH 1/1 Remove v850 from linux/elf-em.h
From: Rob Landley <[email protected]>
The v850 port was removed by commits f606ddf42fd4 and 07a887d399b8 in 2008. These #defines are not used in the current kernel.
--- include/uapi/linux/elf-em.h | 3 --- 1 file changed, 3 deletions(-)
include/uapi/linux/elf-em.h +0 -3
@@ -30,7 +30,6 @@#define EM_X86_64 62/* AMD x86-64 */ #define EM_S390 22/* IBM S/390 */ #define EM_CRIS 76/* Axis Communications 32-bit embedded processor */ -#define EM_V850 87/* NEC v850 */ #define EM_M32R 88/* Renesas M32R */ #define EM_MN10300 89/* Panasonic/MEI MN10300, AM33 */ #define EM_OPENRISC 92/* OpenRISC 32-bit embedded processor */
@@ -50,8 +49,6 @@*/ #define EM_ALPHA 0x9026 -/* Bogus old v850 magic number, used by old tools. */ -#define EM_CYGNUS_V850 0x9080/* Bogus old m32r magic number, used by old tools. */ #define EM_CYGNUS_M32R 0x9041/* This is the old interim value for S/390 architecture */
Quoted 15 lines · Rob Landley
From: Rob Landley <[email protected]>
The v850 port was removed by commits
f606ddf42fd4and07a887d399b8in 2008. These #defines are not used in the current kernel.Signed-off-by Rob Landley <[email protected]>--- include/uapi/linux/elf-em.h | 3 --- 1 file changed, 3 deletions(-)include/uapi/linux/elf-em.h +0
-0
include/uapi/linux/elf-em.h line 33
Quoted 4 lines
include/uapi/linux/elf-em.h +0
-1@@ -30,7 +30,6 @@#define EM_X86_64 62/* AMD x86-64 */ #define EM_S390 22/* IBM S/390 */ #define EM_CRIS 76/* Axis Communications 32-bit embedded processor */ -#define EM_V850 87/* NEC v850 */
Can you do this to userspace visible files?
I thought only additions and obvious corrections were allowed. Removing symbols could cause build breakage for something.
Quoted 13 lines
include/uapi/linux/elf-em.h +0
-2#define EM_M32R 88/* Renesas M32R */ #define EM_MN10300 89/* Panasonic/MEI MN10300, AM33 */ #define EM_OPENRISC 92/* OpenRISC 32-bit embedded processor */ @@ -50,8 +49,6 @@*/ #define EM_ALPHA 0x9026 -/* Bogus old v850 magic number, used by old tools. */ -#define EM_CYGNUS_V850 0x9080/* Bogus old m32r magic number, used by old tools. */ #define EM_CYGNUS_M32R 0x9041/* This is the old interim value for S/390 architecture */
Quoted 12 lines · David Daney
Quoted 11 lines · Rob Landley
From: Rob Landley <[email protected]>
The v850 port was removed by commits
f606ddf42fd4and07a887d399b8in 2008.
These #defines are not used in the current kernel.Signed-off-by Rob Landley <[email protected]>--- include/uapi/linux/elf-em.h | 3 --- 1 file changed, 3 deletions(-)
Quoted 12 lines
Quoted 10 lines
include/uapi/linux/elf-em.h +0
-0@@ -30,7 +30,6 @@#define EM_X86_64 62/* AMD x86-64 */ #define EM_S390 22/* IBM S/390 */ #define EM_CRIS 76/* Axis Communications 32-bit embedded processor */
-#defineEM_V85087 /* NEC v850 */Can you do this to userspace visible files?
Commit 6f6f467eaaa0 did and nobody seemed to mind?
Quoted 2 lines
I thought only additions and obvious corrections were allowed. Removing symbols could cause build breakage for something.
There's a /usr/include/elf.h in glibc with 3 times as many EM_BLAH symbols as this one defines. Something that cares about identifying architectures Linux doesn't actually support would presumably use that header instead of this one.
This is the only architecture included in this file that isn't currently supported by Linux (except the mips symbols with the comment about them not being used, which have been there since the first version of the file).
I found this while auditing toybox's "file" command. (We just copied the constant values into our own table, but when making the table I was checking which values the actual Linux ELF loaders in the various arch directories would bind to.)
Rob
Quoted 26 lines · Rob Landley
Quoted 12 lines · David Daney
Quoted 11 lines · Rob Landley
From: Rob Landley <[email protected]>
The v850 port was removed by commits
f606ddf42fd4and07a887d399b8in 2008.
These #defines are not used in the current kernel.Signed-off-by Rob Landley <[email protected]>--- include/uapi/linux/elf-em.h | 3 --- 1 file changed, 3 deletions(-)Quoted 12 lines
Quoted 10 lines
include/uapi/linux/elf-em.h +0
-0@@ -30,7 +30,6 @@#define EM_X86_64 62/* AMD x86-64 */ #define EM_S390 22/* IBM S/390 */ #define EM_CRIS 76/* Axis Communications 32-bit embedded processor */
-#defineEM_V85087 /* NEC v850 */Can you do this to userspace visible files?
Quoted 1 line
Commit
6f6f467eaaa0did and nobody seemed to mind?
Evidence of prior art doesn't prove correctness.
Quoted 9 lines
Quoted 3 lines
I thought only additions and obvious corrections were allowed. Removing symbols could cause build breakage for something.
There's a
/usr/include/elf.hin glibc with 3 times as manyEM_BLAHsymbols as this one defines. Something that cares about identifying architectures Linux doesn't actually support would presumably use that header instead of this one.
Quoted 8 lines
This is the only architecture included in this file that isn't currently supported by Linux (except the mips symbols with the comment about them not being used, which have been there since the first version of the file).
I found this while auditing toybox's "file" command. (We just copied the constant values into our own table, but when making the table I was checking which values the actual Linux ELF loaders in the various arch directories would bind to.)
The symbols are not hurting anything, they also do not have incorrect values. They are however visible to userspace. I am not going to comment on it any more, but there is a higher burden for removing things that might break userspace programs, than there is for removing code guaranteed not to be userspace visible.
I think the admonition about not breaking userspace has to be considered in this case.
It could be that there is nothing that uses these symbols, but we have no way of knowing for sure. So, unless there is a compelling reason to do this, the lowest risk strategy is to do nothing.
David Daney
Quoted 7 lines · David Daney
Quoted 4 lines · Rob Landley
Quoted 1 line · David Daney
Can you do this to userspace visible files?
Commit
6f6f467eaaa0did and nobody seemed to mind?Evidence of prior art doesn't prove correctness.
It proves that you can, in fact, do this, by showing it's been done before. It doesn't run anything through a theorem prover, I just answered your question.
Quoted 7 lines
Quoted 4 lines
I found this while auditing toybox's "file" command. (We just copied the constant values into our own table, but when making the table I was checking which values the actual Linux ELF loaders in the various arch directories would bind to.)
The symbols are not hurting anything, they also do not have incorrect values.
These are the only values for an architecture we don't support. All the other values are for architectures we support. (Yes, I went through the full list. The only two not in use by an elf loader are the two MIPS ones with the comment about being unused, but they've been around forever and we still support mips.)
Quoted 7 lines
They are however visible to userspace. I am not going to comment on it any more, but there is a higher burden for removing things that might break userspace programs, than there is for removing code guaranteed not to be userspace visible.
I think the admonition about not breaking userspace has to be considered in this case.
You objected, I explained why I disagreed, you then replied that it must be considered. So my previous email didn't count as "considering". (Only agreement counts as considering?)
As I explained last email, userspace uses the libc header, not the linux header, when it wants symbols for architectures Linux does not support. Symbols Linux stopped supporting have been removed from this particular header before. These are the only current "leaked" symbols in this file. I cc'd the guy who removed them, in case he had a reason for keeping them.
Quoted 3 lines
It could be that there is nothing that uses these symbols, but we have no way of knowing for sure. So, unless there is a compelling reason to do this, the lowest risk strategy is to do nothing.
The lowest risk strategy is usually to do nothing. Your machine could be getting exploited connecting to the net to read this email. You are exposing yourself to risk every time you inhale.
Quoted 1 line
David Daney
Rob
On 03/17/2016 07:32 PM, Rob Landley wrote:
[...]
Quoted 3 lines
As I explained last email, userspace uses the libc header, not the linux header,
The fallacy in this argument is the assertion that we know what userspace does.
Userspace could easily do:
#include <linux/elf-em.h>
.
.
.
case SYMBOL_YOU_WANT_TO_REMOVE:
¡BOOM! it is broken.
Quoted 1 line · David Daney
I am not going to comment on it any more, but [commenting more]
Yes you are. (And did then too.)
Quoted 8 lines · Rob Landley
[...]
Quoted 3 lines
As I explained last email, userspace uses the libc header, not the linux header,
The fallacy in this argument is the assertion that we know what userspace does.
Userspace programs that did that already broke on earlier symbol removals.
Quoted 7 lines
Userspace could easily do:
#include <
linux/elf-em.h>
.
caseSYMBOL_YOU_WANT_TO_REMOVE:¡BOOM! it is broken.
So you're assuming I don't know how headers get used by userspace. That's nice. Clearly, I never would have thought of that.
Once again, "As I explained last email", symbols have been removed from this particular header before. Therefore userspace programs that did that without an #ifdef would have been broken by the previous commits that removed symbols. There is a header they can use, provided by libc, which exports all the defined ELF symbols _including_ the symbols the Linux kernel does not suse. The Linux kernel header in question only exports the symbols that this particular kernel version supports. When architectures are added or removed, the corresponding symbols get added or removed. I didn't invent the concept, it's happened before to this header.
(In a larger context, we've removed bigger things. Remember when there was a feature-removal-schedule.txt that listed things pending removal, before Linus decided it was unnecessary and to just use his own judgement? Yeah, take it up with him.)
And now I'm going to take your advice above. Please refer to my earlier messages in this thread for answers to what you're about to say.
Rob
Quoted 18 lines · Rob Landley
Quoted 1 line · David Daney
I am not going to comment on it any more, but [commenting more]
Yes you are. (And did then too.)
Quoted 8 lines · Rob Landley
[...]
Quoted 3 lines
As I explained last email, userspace uses the libc header, not the linux header,
The fallacy in this argument is the assertion that we know what userspace does.
Userspace programs that did that already broke on earlier symbol removals.
Quoted 2 lines
Userspace could easily do:
Quoted 7 lines
Quoted 5 lines
#include <
linux/elf-em.h>
.
caseSYMBOL_YOU_WANT_TO_REMOVE:¡BOOM! it is broken.
So you're assuming I don't know how headers get used by userspace.
Yes, exactly. Don't feel bad about it though, because nobody else knows either.
Quoted 4 lines
That's nice. Clearly, I never would have thought of that.
Once again, "As I explained last email", symbols have been removed from this particular header before.
Since you know, a priori, that symbols in that file are never used by userspace, why not send a patch that moves it to include/linux/elf-em.h so that userspace doesn't see it? Then you could remove as many symbols as you like.
David Daney
[...]