linux-kernel - Re: [Y2038] Question regarding support of old time interfaces beyond y2038

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]

Message-ID: <CAKCAbMjiW8=X1u8nm6nEkAz+MyF=msN97Fr59=v01HbHb=U6UA@mail.gmail.com>
Date:   Tue, 5 Mar 2019 11:05:52 -0500
From:   Zack Weinberg <zackw@...ix.com>
To:     Lukasz Majewski <lukma@...x.de>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Joseph Myers <joseph@...esourcery.com>,
        GNU C Library <libc-alpha@...rceware.org>
Subject: Re: [Y2038] Question regarding support of old time interfaces beyond y2038

On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski <lukma@...x.de> wrote:
> From other discussion [4] - regarding the following system calls:
>  time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm,
>  getitimer, setitimer, select, utime, utimes, futimesat, and
>  {old,new}{l,f,}stat{,64}.
>
> "These all pass 32-bit time_t arguments on 32-bit
>  architectures and are replaced by other interfaces (e.g. posix
>  timers and clocks, statx). C libraries implementing 64-bit time_t in
>  32-bit architectures have to implement the handles by wrapping
>  around the newer interfaces."

1) We should be clear that most of these will continue to be supported
as C library interfaces even if they are not system calls.  Some of
them are obsolete enough and/or rarely used enough that we might not
bother (the older ways to set the system clock, for instance).

2) I know of one case where the new interfaces don't cover all of the
functionality of the old ones: timers started by setitimer continue to
run after an execve, timers started by timer_create don't.  This means
setitimer(ITIMER_VIRTUAL) can be used to impose a CPU time limit on a
program you didn't write, and timer_create can't.  If new kernels are
not going to have setitimer as a primitive, we need some other way of
getting the same effect.

zw