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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180718163153.ogfriudjw7ztwpag@cs.cmu.edu>
Date:   Wed, 18 Jul 2018 12:31:53 -0400
From:   Jan Harkes <jaharkes@...cmu.edu>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Deepa Dinamani <deepa.kernel@...il.com>
Subject: Re: [PATCH] [RESEND] coda: stop using 'struct timespec' in user API

On Wed, Jul 18, 2018 at 06:10:29PM +0200, Arnd Bergmann wrote:
> On Wed, Jul 18, 2018 at 5:50 PM, Jan Harkes <jaharkes@...cmu.edu> wrote:
> > 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).
> 
> Ok, so to make sure I get this right, you say we can do an
> incompatible ABI change for coda without causing any problems
> for existing users?
> 
> That would definitely be the easiest approach here. I guess
> we also just have to be incompatible for 32-bit user space,
> since it would make 32-bit users have the same ABI as 64-bit
> ones, right?
> 
> I'll have another look at the ABI side then, to see how it can
> be transitioned.

Correct, the first thing a client does after opening the /dev/cfs0
device is to send a CIOC_KERNEL_VERSION ioctl. In response the Coda
kernel module returns the current value of CODA_KERNEL_VERSION.

Right now anything but 3 will make the client complain about version
mismatch and refuse to start. It is trivial to allow existing 64-bit
clients to accept both 3 and 4 as valid, and when 32-bit userspace is
updated to also use 64-bit timespec it can be changed to accept only 4.

> >> > 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.
> 
> Ok, I found davfs2 at http://dav.sourceforge.net/index.shtml
> 
> Ah, so the coda kernel implementation is similar to both fuse and 9pfs
> in that it can connect to arbitrary user space implementations, but with
> no known users other than your coda user space and some versions of
> davfs2?

Correct and since the FUSE api is easier to work with it has seen more
users. AFAIK, the work on davfs2 was started before FUSE existed.

Jan