linux-kernel - Re: [GIT PULL v2] timestamp fixes

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: <ZQ9hvS4m775EosEm@mit.edu>
Date:   Sat, 23 Sep 2023 18:07:57 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Amir Goldstein <amir73il@...il.com>,
        Jeff Layton <jlayton@...nel.org>,
        Christian Brauner <brauner@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jan Kara <jack@...e.cz>, "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [GIT PULL v2] timestamp fixes

On Sat, Sep 23, 2023 at 01:03:56PM -0700, Linus Torvalds wrote:
> 
> Except it looks like ext4 actually does full nanosecond resolution (30
> bits for nanoseconds, 34 bits for seconds). Thus the "only a couple of
> hundred years of range".

Hmm, yeah, sorry, I misremembered.  We did talk about possibly going
with 100ns, but if I recall correctly, I think there was a desire that
an arbitrary timespec64 should be encodable into an on-disk timestamp,
and then back again, and hundreds of years of range was considered
Good Enough (tm).

> Except we'd do it without the EXT4_EPOCH_MASK conditionals, and I
> think it would be better to have a bigger range for seconds. If you
> give the seconds field three extra bits, you're comfortable in the
> "thousands of years", and you still have 27 bits that can encode a
> decimal "100ns".

I might be screweing my math, but I believe 24 bits should be enough
to code 10,000,000 units of 100ns (it's enough for 16,777,216), which
should be sufficient.  What am I missing?

As far as how many seconds are needed, that's an area where people of
good will can disagree.  Given that I don't really believe a machine
is going to be up for decades before we will need to reboot and update
the kernel to address zero days, and LTS kernels are going to be
supported for two years going forward, if what we're talking about is
the in-memory time type, my personal opinion is that hundreds of years
is plenty, since it's not hard to change the encoding later.

Cheers,

						- Ted