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/[email protected]/
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.)
On Sun, 5 May 2019 18:10:54 +0400
Stepan Golosunov <[email protected]> wrote:
> 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/[email protected]/
>
> but it doesn't seem like it has reached Linus yet.
>
I hope that this patch will be pulled soon (before final cut) - for that
reason we can assume that the padding is ignored by the kernel and
hence do not explicitly clear it in glibc (as it was done in sent
patches)
>
> (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.)
Please correct me if I'm wrong, but this problem is related to x32
machines (and not to ARM 32 bit ones with Y2038).
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [email protected]