linux-kernel - Re: [RFC PATCH] vfs: Use 12:20 bit major:minor in stat everywhere

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]

Date:	Tue, 3 Mar 2015 17:10:22 -0800
From:	Daniel Ehrenberg <dehrenberg@...gle.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Gwendal Grignou <gwendal@...omium.org>,
	Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Subject: Re: [RFC PATCH] vfs: Use 12:20 bit major:minor in stat everywhere

On Tue, Mar 3, 2015 at 4:53 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Tue, Mar 03, 2015 at 04:37:00PM -0800, Dan Ehrenberg wrote:
>> Previously, stat on 32-bit platforms used old-style encoding and
>> validation of major-minor pairs, with 8:8 bits. However, dev_t is
>> 32-bits on these platforms, and coreutils seems to be treating the
>> values as 12:20 new-style values. The only reason to use the old
>> version is in the implementation of a legacy filesystem format which
>> only has 16 bits of space. Communicating a 12:20 value to userspace
>> when sizeof dev_t == 4 can be done on either a 32-bit or 64-bit
>> platform.
>>
>> This patch removes the artificial restriction in major:minor size.
>> The only backwards incompatibility which results is sometimes stat
>> succeeds if -EOVERFLOW would be returned otherwise. The legacy
>> old-style stat call is retained as-is.
>
> Umm...  You do realize that coreutils are _very_ far from being the only
> userland programs handling the data returned by stat(2), right?
>
> What's to guarantee that your ABI change won't break any of those?

I guess it's impossible to guarantee, but if there is an error, it'll
be that an -EOVERFLOW error is suppressed and the high bits of the
major:minor pair are shaved off by the userspace program. I would
suspect that this would just make debugging harder, rather than
actually break an automated program which counts on getting EOVERFLOW
from a huge block device, but no way to know. The block device has to
actually exist for this to happen, and all we're talking about is stat
failing. So it's replacing an an error code with erroneous way to get
data about a device node (erroneous just because userspace ignores
some of the bits with the answer).

How about this instead: a new config option to switch on the 12:20
major:minor numbers on 32-bit platforms?

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/