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
