Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752943AbcCRCdU (ORCPT ); Thu, 17 Mar 2016 22:33:20 -0400 Received: from mail-ob0-f181.google.com ([209.85.214.181]:35973 "EHLO mail-ob0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbcCRCdI (ORCPT ); Thu, 17 Mar 2016 22:33:08 -0400 Subject: Re: [PATCH] Remove v850 from linux/elf-em.h To: David Daney References: <56E87A63.8020703@landley.net> <56E89928.1010008@gmail.com> <56E90733.4010805@landley.net> <56EB2B0B.7080209@gmail.com> Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , Greg Ungerer From: Rob Landley Message-ID: <56EB68B0.8060208@landley.net> Date: Thu, 17 Mar 2016 21:32:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56EB2B0B.7080209@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2408 Lines: 56 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