linux-kernel - Re: [PATCH] afs: use a consistent interpretation of time values

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: <CAK8P3a3hjbBKyoUS_3fbhgioPv4V+2H9Y4i_C+xwJsHJxrLE+w@mail.gmail.com>
Date:   Wed, 20 Jun 2018 14:00:17 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     David Howells <dhowells@...hat.com>
Cc:     y2038 Mailman List <y2038@...ts.linaro.org>,
        Anna Schumaker <anna.schumaker@...app.com>,
        linux-afs@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] afs: use a consistent interpretation of time values

On Wed, Jun 20, 2018 at 12:53 PM, David Howells <dhowells@...hat.com> wrote:
> Arnd Bergmann <arnd@...db.de> wrote:
>
>> which avoids the y2038 overflow
>
> No it doesn't.  The AFS protocol is limited.
>
>> +     time64_t                mtime_client;   /* last time client changed data */
>> +     time64_t                mtime_server;   /* last time server changed data */
>> ...
>> -     time_t                  creation;       /* volume creation time */
>> +     time64_t                creation;       /* volume creation time */
>
> Unless you can change the AFS protocol, this is a waste of memory.  It might
> be better to change them to u32 as they are protocol values rather than system
> values.

AFS uses 'unsigned' seconds, right? What I was trying to say there is
that with the patch, the 32-bit overflow gets moved from 2038 to 2106, so at
least the nearer problem is solved.

On 64-bit machines, we already waste a little memory here, the usual
tradeoff I took was to use time64_t for all time storage when possible for
clarity reasons, but that is easily changed if you prefer.

>> -     inode->i_ctime.tv_sec   = get_seconds();
>> -     inode->i_ctime.tv_nsec  = 0;
>> -     inode->i_atime          = inode->i_mtime = inode->i_ctime;
>> +     inode->i_ctime = inode->i_atime = inode->i_mtime = current_time(inode);
>
> Surely, the tv_nsec should be zero since anything else cannot be represented
> in the AFS protocol.

current_time() truncates the nanoseconds to the granularity of the filesystem.
Since AFS doesn't set s_time_gran, it gets the default 1000000000 value
leads to tv_nsec being zero. Once Deepa's patch to truncate the tv_sec
range lands, it will also ensure that this is within the range (this is less
of a problem for setting the current time than it is for utimensat() which
can set arbitrary future timestamps of course).

> I will grant, however, I should be consistently using them as unsigned values.
>
> Note that the answers to the above may change if and when I start supporting
> the YFS protocol extensions, but for the AFS protocol, this is simply not
> there.

Ok, good to know this exists.

      Arnd