linux-ext4 - Re: "beyond 2038" warnings from loopback mount is noisy

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: <20190904125834.GA3044@mit.edu>
Date:   Wed, 4 Sep 2019 08:58:34 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Deepa Dinamani <deepa.kernel@...il.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Qian Cai <cai@....pw>,
        Jeff Layton <jlayton@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Andreas Dilger <adilger.kernel@...ger.ca>
Subject: Re: "beyond 2038" warnings from loopback mount is noisy

On Tue, Sep 03, 2019 at 09:50:09PM -0700, Deepa Dinamani wrote:
> If we don't care to warn about the timestamps that are clamped in
> memory, maybe we could just warn when they are being written out.
> Would something like this be more acceptable? I would also remove the
> warning in ext4.h. I think we don't have to check if the inode is 128
> bytes here (Please correct me if I am wrong). If this looks ok, I can
> post this.

That's better, but it's going to be misleading in many cases.  The
inode's extra size field is 16 or larger, there will be enough space
for the timestamps, so talking about "timestamps on this inode beyond
2038" when ext4 is unable to expand it from say, 24 to 32, won't be
true.  Certain certain features won't be available, yes --- such as
project-id-based quotas, since there won't be room to store the
project ID.  However, it's not going to impact the ability to store
timestamps beyond 2038.  The i_extra_isize field is not just about
timestamps!

Again, the likelihood that there will be file systems that have this
problem in 2038 is... extremely low in my judgement.  Storage media
just doesn't last that long; and distributions such as Red Hat and
SuSE very strongly encourage people to reformat file systems and do
*not* support upgrades from ext3 to ext4 by using tune2fs.  If you do
this, their help desk will laugh at you and refuse to help you.

Companies like Google will do this kind of upgrades[1], sure.  But
that's because backing up and reformatting vast numbers of file
systems are not practical at scale.  (And even Google doesn't maintain
the file system image when the servers are old enough to be TCO
negative and it's time to replace them.)

In contrast, most companies / users don't do this sort of thing at
all.  It's not an issue for Cell Phones, for example, or most consumer
devices, which are lucky if the last more than 3 years before they get
desupported and stop getting security updates, and then the lithium
ion batttery dies and the device end up in a landfill.  Those that
might live 20 years (although good luck with that for something like,
say, a smart thermostat) aren't going to have a console and no one
will be paying attention to the kernel messages anyway.  So is it
really worth it?  For whom are these messages meant?

[1] https://www.youtube.com/watch?v=Wp5Ehw7ByuU

Cheers,

					- Ted