linux-kernel - Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 18 Jul 2018 11:50:06 -0400
From:   Jan Harkes <jaharkes@...cmu.edu>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jonathan Corbet <corbet@....net>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API

On Wed, Jul 18, 2018 at 01:46:25PM +0200, Arnd Bergmann wrote:
> Unfortunately, this breaks the layout of the coda_vattr structure, so
> we need to redefine that in terms of something that does not change.
> I'm introducing a new 'struct vtimespec' structure here that keeps
> the existing layout, and the same change has to be done in the coda
> user space copy of linux/coda.h before anyone can use that on a 32-bit
> architecture with 64-bit time_t.

I think the userbase is small enough that we can handle a much simpler
transition to 64-bit timespecs everywhere. In that case the
CODA_KERNEL_VERSION should be updated, which is currently defined in
include/uapi/linux/coda.h as 3. As moving to 64-bit timespecs only
breaks 32-bit systems this allows userspace to catch that case and
refuse to run userspace with a mismatched layout (or handle
translation).

It also would make how to handle questions about truncation moot, or at
least moves the problem out of the kernel into userspace.  We actually
were already using unsigned integers for timestamps in the client <->
server protocol, so as you noted, that does give us a little breather
until 2106.

> Originally sent on June 19, which lead to a short discussion
> and an Ack, but the patch did not get picked up for 4.19 yet.

I'm sorry, somehow I missed the follow up questions in that discussion.

> > 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.

At some point there was a webdav filesystem that used the Coda kernel
apis, but I think they may have moved to FUSE since then so I would not
be surprised if there is only a single code base at this point.

Jan