linux-kernel - Re: [PATCH] Remove v850 from linux/elf-em.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56EB68B0.8060208@landley.net>
Date:	Thu, 17 Mar 2016 21:32:16 -0500
From:	Rob Landley <rob@...dley.net>
To:	David Daney <ddaney.cavm@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Ungerer <gerg@...pgear.com>
Subject: Re: [PATCH] Remove v850 from linux/elf-em.h

On 03/17/2016 05:09 PM, David Daney wrote:
> On 03/16/2016 12:11 AM, Rob Landley wrote:
>> On 03/15/2016 06:22 PM, David Daney wrote:
>>> Can you do this to userspace visible files?
>>
>> Commit 6f6f467eaaa0 did 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.

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

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

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

> David Daney

Rob