Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

From: "Theodore Ts'o" <tytso@mit.edu>
To: Jeff Layton <jlayton@kernel.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christian Brauner" <brauner@kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"David Sterba" <dsterba@suse.cz>,
	"Amir Goldstein" <amir73il@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Jeremy Kerr" <jk@ozlabs.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Carlos Llamas" <cmllamas@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Mattia Dongili" <malattia@linux.it>,
	"Dennis Dalessandro" <dennis.dalessandro@cornelisnetworks.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Leon Romanovsky" <leon@kernel.org>,
	"Brad Warrum" <bwarrum@linux.ibm.com>,
	"Ritu Agarwal" <rituagar@linux.ibm.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Eric Van Hensbergen" <ericvh@kernel.org>,
	"Latchesar Ionkov" <lucho@ionkov.net>,
	"Dominique Martinet" <asmadeus@codewreck.org>,
	"Christian Schoenebeck" <linux_oss@crudebyte.com>,
	"David Sterba" <dsterba@suse.com>,
	"David Howells" <dhowells@redhat.com>,
	"Marc Dionne" <marc.dionne@auristor.com>,
	"Ian Kent" <raven@themaw.net>,
	"Luis de Bethencourt" <luisbg@kernel.org>,
	"Salah Triki" <salah.triki@gmail.com>,
	"Tigran A. Aivazian" <aivazian.tigran@gmail.com>,
	"Chris Mason" <clm@fb.com>, "Josef Bacik" <josef@toxicpanda.com>,
	"Xiubo Li" <xiubli@redhat.com>,
	"Ilya Dryomov" <idryomov@gmail.com>,
	"Jan Harkes" <jaharkes@cs.cmu.edu>,
	coda@cs.cmu.edu, "Joel Becker" <jlbec@evilplan.org>,
	"Christoph Hellwig" <hch@lst.de>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Gao Xiang" <xiang@kernel.org>, "Chao Yu" <chao@kernel.org>,
	"Yue Hu" <huyue2@gl0jj8bn.sched.sma.tdnsstic1.cn>,
	"Jeffle Xu" <jefflexu@linux.alibaba.com>,
	"Namjae Jeon" <linkinjeon@kernel.org>,
	"Sungjong Seo" <sj1557.seo@samsung.com>,
	"Jan Kara" <jack@suse.com>,
	"Andreas Dilger" <adilger.kernel@dilger.ca>,
	"Jaegeuk Kim" <jaegeuk@kernel.org>,
	"OGAWA Hirofumi" <hirofumi@mail.parknet.co.jp>,
	"Christoph Hellwig" <hch@infradead.org>,
	"Miklos Szeredi" <miklos@szeredi.hu>,
	"Bob Peterson" <rpeterso@redhat.com>,
	"Andreas Gruenbacher" <agruenba@redhat.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Anton Ivanov" <anton.ivanov@cambridgegreys.com>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Mikulas Patocka" <mikulas@artax.karlin.mff.cuni.cz>,
	"Mike Kravetz" <mike.kravetz@oracle.com>,
	"Muchun Song" <muchun.song@linux.dev>, "Jan Kara" <jack@suse.cz>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Dave Kleikamp" <shaggy@kernel.org>, "Tejun Heo" <tj@kernel.org>,
	"Trond Myklebust" <trond.myklebust@hammerspace.com>,
	"Anna Schumaker" <anna@kernel.org>,
	"Chuck Lever" <chuck.lever@oracle.com>,
	"Neil Brown" <neilb@suse.de>,
	"Olga Kornievskaia" <kolga@netapp.com>,
	"Dai Ngo" <Dai.Ngo@oracle.com>, "Tom Talpey" <tom@talpey.com>,
	"Ryusuke Konishi" <konishi.ryusuke@gmail.com>,
	"Anton Altaparmakov" <anton@tuxera.com>,
	"Konstantin Komarov" <almaz.alexandrovich@paragon-software.com>,
	"Mark Fasheh" <mark@fasheh.com>,
	"Joseph Qi" <joseph.qi@linux.alibaba.com>,
	"Bob Copeland" <me@bobcopeland.com>,
	"Mike Marshall" <hubcap@omnibond.com>,
	"Martin Brandenburg" <martin@omnibond.com>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Iurii Zaikin" <yzaikin@google.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	"Anders Larsen" <al@alarsen.net>,
	"Steve French" <sfrench@samba.org>,
	"Paulo Alcantara" <pc@manguebit.com>,
	"Ronnie Sahlberg" <lsahlber@redhat.com>,
	"Shyam Prasad N" <sprasad@microsoft.com>,
	"Sergey Senozhatsky" <senozhatsky@chromium.org>,
	"Phillip Lougher" <phillip@squashfs.org.uk>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Evgeniy Dushistov" <dushistov@mail.ru>,
	"Chandan Babu R" <chandan.babu@oracle.com>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	"Naohiro Aota" <naohiro.aota@wdc.com>,
	"Johannes Thumshirn" <jth@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>,
	"Stanislav Fomichev" <sdf@google.com>,
	"Hao Luo" <haoluo@google.com>, "Jiri Olsa" <jolsa@kernel.org>,
	"Hugh Dickins" <hughd@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"John Johansen" <john.johansen@canonical.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Stephen Smalley" <stephen.smalley.work@gmail.com>,
	"Eric Paris" <eparis@parisplace.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-rdma@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-usb@vger.kernel.org, v9fs@lists.linux.dev,
	linux-afs@lists.infradead.org, autofs@vger.kernel.org,
	linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org,
	codalist@telemann.coda.cs.cmu.edu, linux-efi@vger.kernel.org,
	linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, gfs2@lists.linux.dev,
	linux-um@lists.infradead.org, linux-mtd@lists.infradead.org,
	jfs-discussion@lists.sourceforge.net, linux-nfs@vger.kernel.org,
	linux-nilfs@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, ntfs3@lists.linux.dev,
	ocfs2-devel@lists.linux.dev,
	linux-karma-devel@lists.sourceforge.net,
	devel@lists.orangefs.org, linux-unionfs@vger.kernel.org,
	linux-hardening@vger.kernel.org, reiserfs-devel@vger.kernel.org,
	linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
	linux-trace-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	bpf@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
	apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org,
	selinux@vger.kernel.org
Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
Date: Thu, 28 Sep 2023 17:26:56 -0400	[thread overview]
Message-ID: <20230928212656.GC189345@mit.edu> (raw)
In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org>

On Thu, Sep 28, 2023 at 01:40:55PM -0400, Jeff Layton wrote:
> 
> Correct. We'd lose some fidelity in currently stored timestamps, but as
> Linus and Ted pointed out, anything below ~100ns granularity is
> effectively just noise, as that's the floor overhead for calling into
> the kernel. It's hard to argue that any application needs that sort of
> timestamp resolution, at least with contemporary hardware. 
> 
> Doing that would mean that tests that store specific values in the
> atime/mtime and expect to be able to fetch exactly that value back would
> break though, so we'd have to be OK with that if we want to try it. The
> good news is that it's relatively easy to experiment with new ways to
> store timestamps with these wrappers in place.

The reason why we store 1ns granularity in ext4's on-disk format (and
accept that we only support times only a couple of centuries into the
future, as opposed shooting for an on-disk format good for several
millennia :-), was in case there was userspace that might try to store
a very fine-grained timestamp and want to be able to get it back
bit-for-bit identical.

For example, what if someone was trying to implement some kind of
steganographic scheme where they going store a secret message (or more
likely, a 256-bit AES key) in the nanosecond fields of the file's
{c,m,a,cr}time timestamps, "hiding in plain sight".  Not that I think
that we have to support something like that, since the field is for
*timestamps* not cryptographic bits, so if we break someone who is
doing that, do we care?

I don't think anyone will complain about breaking the userspace API
--- especially since if, say, the CIA was using this for their spies'
drop boxes, they probably wouldn't want to admit it.  :-)

       	    	     	      	      	    - Ted