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] [day] [month] [year] [list]
Message-ID: <CAK8P3a1jeHCsn4JiJfbC5K+Y0znvrYZcoGTspy6gAdimfC_PXw@mail.gmail.com>
Date:   Tue, 19 Jun 2018 21:19:23 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Arnd Bergmann <arnd@...db.de>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Jonathan Corbet <corbet@....net>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] coda: stop using 'struct timespec' in user API

On Tue, Jun 19, 2018 at 9:13 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, Jun 19, 2018 at 6:56 PM, Jan Harkes <jaharkes@...cmu.edu> wrote:

>>> An open question is what should happen to actual times past y2038,
>>> as they are now truncated to the last valid date when sent to user
>>
>> That is definitely quite a hard problem because this propagates all the
>> way back to the Coda file servers and how they store metadata.
>> In fact the existing client-server protocol only uses 32-bit time in
>> seconds, so we already lose the nanosecond resolution and 64-bit systems
>> don't actually benefit from having the extra bits in their struct timespec.

I couldn't find out enough background for this, maybe you can fill it
in: I see that there is a user space component and a server component,
but I'm not sure if there is exactly one of each, or if there are multiple
implementations that are written against the same interface.

If we only have one code base, it should be fairly straightforward to
make it deal with 'unsigned' timestamps consistently, which would
let the code work fine until 2106 rather than wrapping around from
2038 to 1902.

> > Not exposing an internal kernel datatype is definitely an improvement,
> > so this is an ACK for me.

To clarify: the problem isn't as much the internal kernel type, but the
glibc internal type that we know is going to change with future glibc
versions. This means it is important that the header file change makes
it into every user space program that uses the psdev interface.

    Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ