linux-kernel - Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0B0XK8g4H+4grEru2GKRG91_qKxZ=y8AxaQi9pcPwKRQ@mail.gmail.com>
Date:   Fri, 26 Jan 2018 10:04:43 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Rob Landley <rob@...dley.net>
Cc:     Taras Kondratiuk <takondra@...co.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Jonathan Corbet <corbet@....net>,
        James McMechan <james.w.mcmechan@...il.com>,
        initramfs@...r.kernel.org, Victor Kamensky <kamensky@...co.com>,
        linux-doc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        xe-linux-external@...co.com
Subject: Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description

On Fri, Jan 26, 2018 at 3:39 AM, Rob Landley <rob@...dley.net> wrote:

> The problem with 1 second timestamps was you honestly could confuse
> "make" about which file was newer once an exec() could complete in the
> same second having done real work. That was the motivating issue causing
> the change, going to nanoseconds was just the big hammer of "this is
> large enough it won't matter again in our lifetimes". But nanosecond
> time stamps are recording more jitter than useful information, and that
> seems unlikely to change this century?

Sure, the only thing we really need the nanosecond timestamp for is
to keep them identical. E.g. if you use cpio to make an exact copy
of a file system, using microseconds timestamps will round all mtime
values. If you then use 'rsync' to compare/update the two copies
without passing a --modify-window= or --size-only, it will have
to read all files in rather then skipping those with identical size and
mtime.

Side note: the default behavior for file systems is actually to only use
the coarse timestamps of the last timer tick, so you actually do get
identical timestamps in practice, plus six digits of nonsense:

(on tmpfs)
 $ for i in {000..999} ; do > $i ; done; stat --format="%y" *  | uniq -c
     86 2018-01-26 10:01:48.811135084 +0100
    469 2018-01-26 10:01:48.815135143 +0100
    445 2018-01-26 10:01:48.819135201 +0100

         Arnd