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

[Alistair Francis <alistair23 at gmail dot com>]

On Fri, Aug 30, 2019 at 10:03 AM Zack Weinberg <zackw@panix.com> wrote:
>
> 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'.)

Yes, applying it to master is even better!

Alistair

>
> 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