linux-kernel - Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time

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:   Tue, 28 Nov 2017 15:17:26 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Deepa Dinamani <deepa.kernel@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        John Stultz <john.stultz@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Chris Metcalf <cmetcalf@...lanox.com>, cohuck@...hat.com,
        David Miller <davem@...emloft.net>,
        Helge Deller <deller@....de>, devel@...verdev.osuosl.org,
        gerald.schaefer@...ibm.com, gregkh <gregkh@...uxfoundation.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Jan Hoeppner <hoeppner@...ux.vnet.ibm.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Julian Wiedmann <jwi@...ux.vnet.ibm.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        "open list:RALINK MIPS ARCHITECTURE" <linux-mips@...ux-mips.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        oberpar@...ux.vnet.ibm.com, oprofile-list@...ts.sf.net,
        Paul Mackerras <paulus@...ba.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Robert Richter <rric@...nel.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        sebott@...ux.vnet.ibm.com, sparclinux <sparclinux@...r.kernel.org>,
        Stefan Haberland <sth@...ux.vnet.ibm.com>,
        Ursula Braun <ubraun@...ux.vnet.ibm.com>,
        Will Deacon <will.deacon@....com>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@...il.com> wrote:
>>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>>> legacy time syscalls such as sys_nanosleep because this will need to
>>> enclose compat_sys_nanosleep as well. So, defining it as
>>>
>>> config LEGACY_TIME_SYSCALLS
>>>      def_bool 64BIT || !64BIT_TIME
>>>
>>> will not include compat_sys_nanosleep. We will instead need a new config to
>>> exclusively mark legacy syscalls.
>>
>> Do you mean we would need to do this separately for native and compat
>> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
>> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
>> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
>> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.
>
> I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
> compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
> along with other compat syscalls.
> So, if we define the LEGACY_TIME_SYSCALLS as
>
>
>         "This controls the compilation of 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.
>         New architectures should not explicitly enable this."
>
> This would not be really true as compat interfaces have nothing to do
> with this config.
>
> I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
> then have all these "deprecated" syscalls be enclosed within this,
> compat or not.
> This will also mean that we will have to come up representing these
> syscalls in the syscall header files.
> This can be a separate patch and this series can be merged as is if
> everyone agrees.

I think doing this separately  would be good, I don't see any interdependency
with the other patches, we just need to decide what we want in the long
run.

I agree my text that you cited doesn't capture the situation correctly,
as this is really about the obsolete system calls that take 64-bit time_t
arguments on architectures that are converted to allow 64-bit time_t
for non-obsolete system calls.

Maybe it's better to just reword this to

      "This controls the compilation of 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 are all replaced by other interfaces (e.g. posix timers and clocks,
      statx) on architectures that got converted from 32-bit time_t to
64-bit time_t.
      C libraries implementing 64-bit time_t in 32-bit architectures have to
      implement the handles by wrapping around the newer interfaces.
      New architectures should not explicitly enable this."

That would clarify that it's not about the compat system calls, while
also allowing the two options to be set independently.

        Arnd