linux-kernel - Re: Stability of ioctl constants in the UAPI (Re: [PATCH 01/32] pidfs: validate extensible ioctls)

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] [day] [month] [year] [list]

Message-ID: <20251126114723.GL11602@gnu.wildebeest.org>
Date: Wed, 26 Nov 2025 12:47:23 +0100
From: Mark Wielaard <mark@...mp.org>
To: strace development discussions <strace-devel@...ts.strace.io>
Cc: Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Amir Goldstein <amir73il@...il.com>, linux-fsdevel@...r.kernel.org,
	Josef Bacik <josef@...icpanda.com>,
	Jeff Layton <jlayton@...nel.org>, Mike Yuan <me@...dnzj.com>,
	Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>,
	Lennart Poettering <mzxreary@...inter.de>,
	Daan De Meyer <daan.j.demeyer@...il.com>,
	Aleksa Sarai <cyphar@...har.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Koutný <mkoutny@...e.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Chuck Lever <chuck.lever@...cle.com>, linux-nfs@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	netdev@...r.kernel.org, libc-alpha@...rceware.org,
	"Dmitry V. Levin" <ldv@...ace.io>,
	address-sanitizer <address-sanitizer@...glegroups.com>
Subject: Re: Stability of ioctl constants in the UAPI (Re: [PATCH 01/32]
 pidfs: validate extensible ioctls)

Hi,

On Wed, Nov 26, 2025 at 10:08:44AM +0100, Florian Weimer wrote:
> Is this really the right direction?  This implies that the ioctl
> constants change as the structs get extended.  At present, this impacts
> struct pidfd_info and PIDFD_GET_INFO.
> 
> I think this is a deparature from the previous design, where (low-level)
> userspace did not have not worry about the internal structure of ioctl
> commands and could treat them as opaque bit patterns.  With the new
> approach, we have to dissect some of the commands in the same way
> extensible_ioctl_valid does it above.
> 
> So far, this impacts glibc ABI tests.  Looking at the strace sources, it
> doesn't look to me as if the ioctl handler is prepared to deal with this
> situation, either, because it uses the full ioctl command for lookups.
> 
> The sanitizers could implement generic ioctl checking with the embedded
> size information in the ioctl command, but the current code structure is
> not set up to handle this because it's indexed by the full ioctl
> command, not the type.  I think in some cases, the size is required to
> disambiguate ioctl commands because the type field is not unique across
> devices.  In some cases, the sanitizers would have to know the exact
> command (not just the size), to validate points embedded in the struct
> passed to the ioctl.  So I don't think changing ioctl constants when
> extensible structs change is obviously beneficial to the sanitizers,
> either.

Same for valgrind memcheck handling of ioctls.

> I would prefer if the ioctl commands could be frozen and decoupled from
> the structs.  As far as I understand it, there is no requirement that
> the embedded size matches what the kernel deals with.

Yes please.

Thanks,

Mark