linux-kernel - Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 Jul 2017 12:23:41 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Arnd Bergmann <arnd@...db.de>
cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer
 syscalls

On Mon, 26 Jun 2017, Arnd Bergmann wrote:
> On Mon, Jun 26, 2017 at 8:17 PM, Deepa Dinamani <deepa.kernel@...il.com> wrote:
> > On Sun, Jun 25, 2017 at 7:35 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> >> On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote:
> >>> The series aims at isolating data conversions of time_t based structures:
> >>> struct timespec and struct itimerspec at user space boundaries.
> >>> This helps to later change the underlying types to handle y2038 changes
> >>> to these.
> >>
> >> Nice...  A few questions:
> >>
> >> * what about setitimer(2)?  Right now that's the only remaining user of
> >> get_compat_itimerval(); similar for getitimer(2) and put_compat_itimerval().
> >
> > We do not plan to support these beyond y2038 on 32 bit systems.
> > timer_settime() and timer_gettime() are considered to be replacements
> > for these, respectively.
> >
> > There is also going to be a cleanup of timeval/ timespec/ time_t data
> > types and apis after the new syscalls are ready.
> > At that time I might choose to get rid of these itimerval apis. I'm
> > not sure yet.
> 
> I see that internally, alarm/getitimer/setitimer all use ktime_t, so
> one possible solution would be to push down the use of ktime_t
> into the callers and do both the conversion and range check in the
> user copy function.

We still can decide to not support the itimer API with the new y2038 ready
syscalls.

Actually there is no real need to do so because the itimer interfaces are
relative and never absolute. Keeping relative time limited to 68 years from
now should be good enough :)

Thanks,

	tglx