linux-kernel - Re: [PATCH] block: fix FS_IOC_GETLBMD_CAP parsing in blkdev_common

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aG-dI2wJDl-HfzFG@infradead.org>
Date: Thu, 10 Jul 2025 03:59:47 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Christoph Hellwig <hch@...radead.org>,
	Christian Brauner <brauner@...nel.org>,
	Arnd Bergmann <arnd@...nel.org>, linux-fsdevel@...r.kernel.org,
	linux-block@...r.kernel.org, Anuj Gupta <anuj20.g@...sung.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Kanchan Joshi <joshi.k@...sung.com>, LTP List <ltp@...ts.linux.it>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	Benjamin Copeland <benjamin.copeland@...aro.org>, rbm@...e.com,
	Naresh Kamboju <naresh.kamboju@...aro.org>,
	Anders Roxell <anders.roxell@...aro.org>,
	Jens Axboe <axboe@...nel.dk>,
	Pavel Begunkov <asml.silence@...il.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"Darrick J. Wong" <djwong@...nel.org>,
	Eric Biggers <ebiggers@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: fix FS_IOC_GETLBMD_CAP parsing in
 blkdev_common_ioctl()

On Thu, Jul 10, 2025 at 12:50:44PM +0200, Arnd Bergmann wrote:
> There are multiple methods we've used to do this in the past,
> but I don't think any of them are great, including the version
> that Christian is trying to push now:
> 
> The most common variant is to leave extra room at the end of
> a structure and use that as in your 1fd8159e7ca4 ("xfs: export zoned
> geometry via XFS_FSOP_GEOM") and many other examples.

That's using the space.  I had that discussion before in context of
this API, and I still think that reserving a small amount of space
that can be used for extensions is usually good practice.  Often
we get some of that for free by 64-bit aligning anyway, and adding
a bit more tends to also be useful.

> This is probably the easiest and it only fails once you run out of
> spare room and have to pick a new command number. A common mistake
> here is to forget checking the padding in the input data against
> zero, so old kernels just ignore whatever new userspace tried
> to pass.
> 
> I think the variant from commit 1b6d968de22b ("xfs: bump
> XFS_IOC_FSGEOMETRY to v5 structures") where the old structure
> gets renamed and the existing macro refers to a different
> command code is more problematic. We used to always require
> userspace to be built against the oldest kernel headers it could run
> on. This worked fine in the past but it appears that userspace
> (in particular glibc) has increasingly expected to also work
> on older kernels when building against new headers.

This is what I meant.  Note that the userspace in this case also keeps a
case trying the old structure, but that does indeed require keeping the
userspace somewhat in lockstep if you do the renaming as in this example.
The better example would be one using a new new for the extended
structure, or requiring a feature macro to get the larger structure.

> Christian's version using the copy_struct_{from,to}_user()
> aims to avoid most of the problems. The main downside I see
> here is the extra complexity in the kernel. As far as I can
> tell, this has mainly led to extra kernel bugs but has not
> actually resulted in any structure getting seamlessly
> extended.

That is my (non-scientific) impression as well.