02.05.2019 в 15:04:18 +0000 Joseph Myers написал: > On Tue, 30 Apr 2019, Lukasz Majewski wrote: > > > - The need for explicit clearing padding when calling syscalls (as to > > be better safe than sorry in the future - there was related > > discussion started by Stepan). > > This really isn't a difficult question. What it comes down to is whether > the Linux kernel, in the first release version with these syscalls (we > don't care about old -rc versions; what matters is the actual 5.1 > release), ignores the padding. > > If 5.1 *release* ignores the padding, that is part of the kernel/userspace > ABI, in accordance with the kernel principle of not breaking userspace. > Thus, it is something userspace can rely on, now and in the future. > > If 5.1 release does not ignore the padding, syscall presence does not mean > the padding is ignored by the kernel and so glibc needs to clear padding. > Of course, it needs to clear padding in a *copy* of the value provided by > the user unless the glibc API in question requires the timespec value in > question to be in writable memory. > > So, which is (or will be) the case in 5.1 release? Padding ignored or > not? If more complicated (ignored for some architectures / ABIs but not > for others, or depending on whether compat syscalls are in use), then say > so - give a precise description of the exact circumstances under which the > padding around a 32-bit tv_nsec will or will not be ignored by the kernel > on input from userspace.
In current linux git it looks like padding is correctly ignored in 32-bit kernels (because kernel itself has 32-bit tv_nsec there) but the code to clear it on compat syscalls in 64-bit kernels seems to be broken. The patch to fix this is at https://lore.kernel.org/lkml/20190429131951.471701-1-a...@arndb.de/ but it doesn't seem like it has reached Linus yet. (Hmm. I think that old ipc and socketcall syscalls in 32-bit kernels are broken without that patch too. They would try to read __kernel_timespec when callers are passing old_timespec32.)
