linux-kernel - Re: [PATCH] nfds: avoid gettimeofday for nfssvc

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: <20171020191935.GE15211@fieldses.org>
Date:   Fri, 20 Oct 2017 15:19:35 -0400
From:   "J. Bruce Fields" <bfields@...ldses.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jeff Layton <jlayton@...hat.com>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Trond Myklebust <trond.myklebust@...marydata.com>,
        NeilBrown <neilb@...e.com>, Kinglong Mee <kinglongmee@...il.com>,
        linux-nfs@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nfds: avoid gettimeofday for nfssvc_boot time

On Thu, Oct 19, 2017 at 01:04:35PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 19, 2017 at 12:54 PM, Jeff Layton <jlayton@...hat.com> wrote:
> >
> > I wonder if we'd be better off just using nfssvc_boot.tv_sec as the
> > verifier? I don't see us ever calling that ktime_get_real_ts64 more than
> > once per second for this purpose, and that would eliminate wraparound.
> > That said, wraparound is not a huge concern here anyway, so this is
> > certainly fine for now:

It might reduce the chances of a collision if someone is doing extreme
boot-time optimization, or if time goes backwards for some reason?

> I now have the feeling that we had previously had the same discussion
> when someone else submitted a similar patch that ended up never getting
> merged. I might also be confusing this with a different subsystem that
> had the same requirement.
> 
> If we want this to be as unique as possible and also never (within
> a few hundred years) wrap, we could call ktime_get_real_ns(), which
> returns a 64-bit nanoseconds number.

Anyway, no objection to doing this differently if someone wants, but
I'll just take this patch for now.

Thanks.--b.

> 
> > Reviewed-by: Jeff Layton <jlayton@...hat.com>
> 
> Thanks.
> 
>      Arnd