Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define

[Zack Weinberg <zackw at panix dot com>]

On Thu, Aug 29, 2019 at 6:00 PM Alistair Francis <alistair23@gmail.com> wrote:
> On Thu, Aug 29, 2019 at 1:24 PM Joseph Myers <joseph@codesourcery.com> wrote:
> > On Wed, 28 Aug 2019, Zack Weinberg wrote:
> > > OK, how does this look?
> >
> > This version is OK.
>
> Great! Thanks for your help Zack.
>
> Do you want to send this out as a patch?

I could just go ahead and apply it to master, maybe that would be the
simplest thing?  Or would you prefer to incorporate it into either
your patch series or Lukasz' patch series, so that it lands along with
the rest of the work?  (In the latter case, you should be able to feed
my previous message directly to 'git am'.)

On Wed, Aug 28, 2019 at 5:46 PM Lukasz Majewski <lukma@denx.de> wrote:
> > +#ifndef _LINUX_KERNEL_FEATURES_H
> > +#define _LINUX_KERNEL_FEATURES_H 1
>
> I assume that the above is just plain "guard" define (without any extra
> meaning for glibc or other library)?

Yes.  We have a lot of internal headers that are missing
multiple-inclusion guards, so for some time now, whenever I need to
modify an internal header that doesn't have a guard, I add one at the
same time.

On Fri, Aug 30, 2019 at 12:37 PM Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 30 Aug 2019, Rich Felker wrote:
> > To clarify, none of the timespec ones "exactly match" -- the suffixed
> > syscalls on 32-bit require filling the padding around tv_nsec, whereas
>
> What do you mean by "require filling the padding"?  I thought the
> conclusion in the kernel was that it dealt with zeroing the padding
...

The kernel should always explicitly clear all of the padding in any
structure it writes to user space, anything else risks leaking kernel
data (e.g. the compiler decides it can use a 64-bit load and store to
copy from the kernel's struct timespec to the user space struct
timespec because those high bits are don't-care in the destination
... oops, the previous allocation had a kernel pointer in that 64-bit
slot and we just exposed the KASLR base).

Regardless, though, I don't think the text I wrote needs to mention
this concern, since it actually doesn't talk at all about the "exactly
match" rule.  The set of system calls covered by the new macro is just
listed as a fact.  Please let me know if you disagree?

zw