linux-kernel - Re: [PATCH 5/6] ibmvscsi: Remove unsupported host config MAD and sysfs interface

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: <56B38EE7.6060102@gmail.com>
Date:	Thu, 4 Feb 2016 09:48:23 -0800
From:	Tyrel Datwyler <turtle.in.the.kernel@...il.com>
To:	Johannes Thumshirn <jthumshirn@...e.de>,
	Tyrel Datwyler <tyreld@...ux.vnet.ibm.com>
Cc:	martin.petersen@...cle.com, linux-scsi@...r.kernel.org,
	JBottomley@...n.com, linux-kernel@...r.kernel.org, hare@...e.de,
	brking@...ux.vnet.ibm.com, nfont@...ux.vnet.ibm.com,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 5/6] ibmvscsi: Remove unsupported host config MAD and
 sysfs interface

On 02/04/2016 12:03 AM, Johannes Thumshirn wrote:
> On Wed, Feb 03, 2016 at 05:28:33PM -0600, Tyrel Datwyler wrote:
>> A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in
>> the code for some time. From what information I've gathered from
>> Brian King this was likely implemented on the host side in a SLES 9
>> based VIOS, which is no longer supported anywhere. Further, it is
>> not defined in PAPR or supported by any AIX based VIOS.
>>
>> Treating as bit rot and removing the sysfs interface and associated
>> host config code accordingly.
> 
> Doesn't removing a sysfs interface potentially break userspace code?
> 

In the general case yes, but I feel in this case no. First, Reading from
this config attribute of a vscsi host adapter always returns nothing.
Second, any userspace code using this attribute better be checking for
the existence of config. Just a quick look for
/sys/class/scsi_host/host*/config under other host adapters on my system
I find that attribute doesn't exist for any of them.

If there is truly enough concern that somebody may actually be accessing
this useless attribute from userspace then we can still strip out the
unsupported code, but leave the attribute and return nothing directly
from the show function.

-Tyrel