From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 497359CA71 for ; Thu, 28 Sep 2023 21:27:19 +0000 (UTC) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BA021AA for ; Thu, 28 Sep 2023 14:27:17 -0700 (PDT) Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQvsp021536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936425; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=NGPOVv6aP7Wgx4/k9ruqGjDYWmjUQVAfEL5fppG6yE2RNxUM6uiyoWrXBZfGmZyL2 gb1zEZjWcSSCFd+NWg1/BYhZ5jeEptXNin1ZAM6seg38Angccj8YOPtyzxOx/hDFrb Q+ePr/t98/fHq2BcSzJCThnFTNb50fVmlIrGfb3oMvB11ToZpH+p8R2mhaDk4/44dl uEHGVh6Q6Ih5iyFuN8+PasXijpXT1PXJm+5Rkla8PX5Glna1OAsFe3wre6CQl62oa4 RAr1Z2b44rKF067M11yaRPI56z2wMDur4vLyEnjrhgmaYzW5D9XQ8I+PJlbP887wDq NXSNNWLPWiTbQ== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Cc: "Darrick J. Wong" , Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Mattia Dongili , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Brad Warrum , Ritu Agarwal , Hans de Goede , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Mark Gross , Jiri Slaby , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Sterba , David Howells , Marc Dionne , Ian Kent , Luis de Bethencourt , Salah Triki , "Tigran A. Aivazian" , Chris Mason , Josef Bacik , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Joel Becker , Christoph Hellwig , Nicolas Pitre , "Rafael J . Wysocki" , Ard Biesheuvel , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Christoph Hellwig , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Mikulas Patocka , Mike Kravetz , Muchun Song , Jan Kara , David Woodhouse , Dave Kleikamp , Tejun Heo , Trond Myklebust , Anna Schumaker , Chuck Lever , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Ryusuke Konishi , Anton Altaparmakov , Konstantin Komarov , Mark Fasheh , Joseph Qi , Bob Copeland , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Iurii Zaikin , Tony Luck , "Guilherme G. Piccoli" , Anders Larsen , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Sergey Senozhatsky , Phillip Lougher , Steven Rostedt , Masami Hiramatsu , Evgeniy Dushistov , Chandan Babu R , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Hugh Dickins , Andrew Morton , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , 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 , 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 Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AB92CE9413E for ; Sat, 7 Oct 2023 02:00:29 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=WaP79h5b; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4S2T5m29pCz3cRY for ; Sat, 7 Oct 2023 13:00:28 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=WaP79h5b; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=lists.ozlabs.org) X-Greylist: delayed 166 seconds by postgrey-1.37 at boromir; Fri, 29 Sep 2023 07:37:10 AEST Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RxRdf0v1Gz3cCG for ; Fri, 29 Sep 2023 07:37:08 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQv6B021535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936431; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=WaP79h5bQ62LFZ7vHHOCmGWKrdVEw7kTPaoOfwjqG7743/KpOeTQfqQpPAFra25uw qHhUQptGls8wmshhyjdnO9G7FinJGRSu/H+Pr36/HOeVsY2L1QKwp6wJYXWDQj3sU6 spxP8X5T3MP/kvZK7FBaCvSP9XyEeM6QQ1hm7OJdJzn5aY8Xu6Fua+baunPXgUoy7L KhVrZIKyvYcsT0NIC33rKKlIWvn/ApA3rOkeZe9sao19Z+JDKma1IeqPjZOBPScT5p +jnf6c81JzZ84Oc7GpEzLi5aGjfgb8lOPxXH2Up3ynLvwNxgs1A65KPgjW+ME/+Top l7dosLTQv306w== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-Mailman-Approved-At: Sat, 07 Oct 2023 12:59:01 +1100 X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Konstantin Komarov , "Rafael J . Wysocki" , "Darrick J. Wong" , Anders Larsen , Carlos Llamas , Andrii Nakryiko , Mattia Dongili , Hugh Dickins , Yonghong Song , Alexander Gordeev , Christoph Hellwig , Mike Marshall , Paulo Alcantara , linux-xfs@vger.kernel.org, Michael Ellerman , James Morris , Christophe Leroy , Christoph Hellwig , Christian Borntraeger , devel@lists.orangefs.org, Shyam Prasad N , linux-um@lists.infradead.org, Nicholas Piggin , Alexander Viro , Eric Van Hensbergen , Suren Baghdasaryan , Trond Myklebust , Anton Altaparmakov , Christian Brauner , Greg Kroah-Hartman , Stephen Smalley , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Sergey Senozhatsky , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Chuck Lever , Sven Schnelle , Jiri Olsa , Jan Kara , Tejun Heo , Andrew Morton , linux-trace-kernel@vger.kernel.org, Linus Torvalds , Dave Kleikamp , linux-mm@kvack.org, Joel Fernandes , Eric Dumazet , Stanislav Fomichev , codalist@telemann.coda.cs.cmu.edu, linux-s390@vger.kernel.org, linux-n ilfs@vger.kernel.org, Paul Moore , Leon Romanovsky , John Fastabend , Luis Chamberlain , Iurii Zaikin , Namjae Jeon , Masami Hiramatsu , Todd Kjos , Vasily Gorbik , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org, Miklos Szeredi , John Johansen , Jaegeuk Kim , Martijn Coenen , OGAWA Hirofumi , Hao Luo , Tony Luck , Nicolas Pitre , linux-ntfs-dev@lists.sourceforge.net, Muchun Song , linux-f2fs-devel@lists.sourceforge.net, "Guilherme G. Piccoli" , gfs2@lists.linux.dev, "Eric W. Biederman" , Anna Schumaker , Brad Warrum , Mike Kravetz , linux-efi@vger.kernel.org, Martin Brandenburg , ocfs2-devel@lists.linux.dev, Alexei Starovoitov , Yue Hu , Chris Mason , linux-mtd@lists.infradead.org, linux-hardening@vger.kernel.org, Marc Dionne , Jiri Slaby , linux-afs@lists.infradead.org, Ian Kent , Naohiro Aota , Daniel Borkmann , Dennis Dalessandro , linux-rdma@vger.kernel.org, coda@cs.cmu.edu, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Ilya Dryomov , Paolo Abeni , "Serge E. Hallyn" , Christian Schoenebeck , Kees Cook , Arnd Bergmann , autofs@vger.kernel.org, Steven Rostedt , Mark Gross , Damien Le Moal , Eric Paris , ceph-devel@vger.kernel.org, Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Olga Kornievskaia , Song Liu , samba-technical@lists.samba.org, Steve French , Jeremy Kerr , Netdev , Bob Peterson , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, ntfs3@lists.linux.dev, linux-erofs@lists.ozlabs.org, "David S . Miller" , Chandan Babu R , jfs-discussion@lists.sourceforge.net, Jan Kara , Neil Brown , Dominique Martinet , Amir Goldstein , Bob Copeland , KP Singh , linux-unionfs@vger.kernel.org, David Howells , Joseph Qi , Andreas Dilger , Mikulas Patocka , Ard Biesheuvel , Anton Ivanov , Andreas Gruenbacher , Richard Weinberger , Mark Fasheh , Dai Ngo , Jason Gunthorpe , linux-serial@vger.kernel.org, Jakub Kicinski , Salah Triki , platform-driver-x86@vger.kernel.org, Evgeniy Dushistov , linux-cifs@vger.kernel.org, Heiko Carstens , apparmor@lists.ubuntu.com, Josef Bacik , Tom Talpey , Hans de Goede , "Tigran A. Aivazian" , David Sterba , Xiubo Li , Ryusuke Konishi , Johannes Thumshirn , Ritu Agarwal , Luis de Bethencourt , Martin KaFai Lau , v9fs@lists.linux.dev, David Sterba , linux-security-module@vger.kernel.org, Phillip Lougher , Johannes Berg , Sungjong Seo , David Woodhouse , linux-karma-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0CB0E743C4 for ; Thu, 28 Sep 2023 21:27:57 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1qlyY6-0003Qt-IT; Thu, 28 Sep 2023 21:27:55 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qlyY5-0003Qm-Q0 for linux-f2fs-devel@lists.sourceforge.net; Thu, 28 Sep 2023 21:27:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; b=UsHIDs5sbVc02WqHEM+tEDQoIB Xqw7sNTCkFsY+8VY4SPGWcs83QChLymjovNX4Y1vg+rCZXUYvRQX1sP1XH8IjPWe+X6eMzB0WZaTY 6jXLWXJcG2+V+Q0SblbHr7eQvmPPly7CxKGaeNu3TnxOwstNoD04yM52o0qGBrQ3tMEw=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; b=O2uKd5HIPPVFnHllZrk2xu61b8 tqXL2qhIWBxop2A/MVp8N8z5BAhv9aEmX0OTN8cxCSZKbc6GnJB0ungVBaudBjnExw3oDgFcm/hHq GmYmCHtrCX2fioDp62a1ioKUZ2u/gXEb3nuwu2ubQ5Lq3FDJo99W7xfwWB+/UtKd6yyQ=; Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1qlyY5-0002Xw-An for linux-f2fs-devel@lists.sourceforge.net; Thu, 28 Sep 2023 21:27:54 +0000 Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQv6B021535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936431; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=WaP79h5bQ62LFZ7vHHOCmGWKrdVEw7kTPaoOfwjqG7743/KpOeTQfqQpPAFra25uw qHhUQptGls8wmshhyjdnO9G7FinJGRSu/H+Pr36/HOeVsY2L1QKwp6wJYXWDQj3sU6 spxP8X5T3MP/kvZK7FBaCvSP9XyEeM6QQ1hm7OJdJzn5aY8Xu6Fua+baunPXgUoy7L KhVrZIKyvYcsT0NIC33rKKlIWvn/ApA3rOkeZe9sao19Z+JDKma1IeqPjZOBPScT5p +jnf6c81JzZ84Oc7GpEzLi5aGjfgb8lOPxXH2Up3ynLvwNxgs1A65KPgjW+ME/+Top l7dosLTQv306w== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-Headers-End: 1qlyY5-0002Xw-An Subject: Re: [f2fs-dev] [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Konstantin Komarov , "Rafael J . Wysocki" , "Darrick J. Wong" , Anders Larsen , Carlos Llamas , Andrii Nakryiko , Mattia Dongili , Hugh Dickins , Yonghong Song , Alexander Gordeev , Christoph Hellwig , Mike Marshall , Paulo Alcantara , linux-xfs@vger.kernel.org, Michael Ellerman , James Morris , Christophe Leroy , Christoph Hellwig , Christian Borntraeger , devel@lists.orangefs.org, Shyam Prasad N , linux-um@lists.infradead.org, Nicholas Piggin , Alexander Viro , Eric Van Hensbergen , Suren Baghdasaryan , Trond Myklebust , Anton Altaparmakov , Christian Brauner , Greg Kroah-Hartman , Stephen Smalley , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Sergey Senozhatsky , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Chuck Lever , Sven Schnelle , Jiri Olsa , Jan Kara , Tejun Heo , Andrew Morton , linux-trace-kernel@vger.kernel.org, Linus Torvalds , Dave Kleikamp , linux-mm@kvack.org, Joel Fernandes , Eric Dumazet , Stanislav Fomichev , codalist@telemann.coda.cs.cmu.edu, linux-s390@vger.kernel.org, linux-nilfs@vger.kernel.org, Paul Moore , Leon Romanovsky , John Fastabend , Luis Chamberlain , Iurii Zaikin , Namjae Jeon , Masami Hiramatsu , Todd Kjos , Vasily Gorbik , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org, Miklos Szeredi , John Johansen , Jaegeuk Kim , Martijn Coenen , OGAWA Hirofumi , Hao Luo , Tony Luck , Nicolas Pitre , linux-ntfs-dev@lists.sourceforge.net, Muchun Song , linux-f2fs-devel@lists.sourceforge.net, "Guilherme G. Piccoli" , gfs2@lists.linux.dev, "Eric W. Biederman" , Anna Schumaker , Brad Warrum , Mike Kravetz , linux-efi@vger.kernel.org, Martin Brandenburg , ocfs2-devel@lists.linux.dev, Alexei Starovoitov , Yue Hu , Chris Mason , linux-mtd@lists.infradead.org, linux-hardening@vger.kernel.org, Marc Dionne , Jiri Slaby , linux-afs@lists.infradead.org, Ian Kent , Naohiro Aota , Daniel Borkmann , Dennis Dalessandro , linux-rdma@vger.kernel.org, coda@cs.cmu.edu, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Ilya Dryomov , Paolo Abeni , "Serge E. Hallyn" , Christian Schoenebeck , Kees Cook , Arnd Bergmann , autofs@vger.kernel.org, Steven Rostedt , Mark Gross , Damien Le Moal , Eric Paris , ceph-devel@vger.kernel.org, Gao Xiang , Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Olga Kornievskaia , Song Liu , samba-technical@lists.samba.org, Steve French , Jeremy Kerr , Netdev , Bob Peterson , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, ntfs3@lists.linux.dev, linux-erofs@lists.ozlabs.org, "David S . Miller" , Chandan Babu R , jfs-discussion@lists.sourceforge.net, Jan Kara , Neil Brown , Dominique Martinet , Amir Goldstein , Bob Copeland , KP Singh , linux-unionfs@vger.kernel.org, David Howells , Joseph Qi , Andreas Dilger , Mikulas Patocka , Ard Biesheuvel , Anton Ivanov , Andreas Gruenbacher , Richard Weinberger , Mark Fasheh , Dai Ngo , Jason Gunthorpe , linux-serial@vger.kernel.org, Jakub Kicinski , Salah Triki , platform-driver-x86@vger.kernel.org, Evgeniy Dushistov , linux-cifs@vger.kernel.org, Heiko Carstens , apparmor@lists.ubuntu.com, Josef Bacik , Tom Talpey , Hans de Goede , "Tigran A. Aivazian" , David Sterba , Xiubo Li , Ryusuke Konishi , Johannes Thumshirn , Ritu Agarwal , Luis de Bethencourt , Martin KaFai Lau , v9fs@lists.linux.dev, David Sterba , linux-security-module@vger.kernel.org, Jeffle Xu , Phillip Lougher , Johannes Berg , Sungjong Seo , David Woodhouse , linux-karma-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, Joel Becker Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Theodore Ts'o" Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Date: Thu, 28 Sep 2023 17:26:56 -0400 Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936425; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=NGPOVv6aP7Wgx4/k9ruqGjDYWmjUQVAfEL5fppG6yE2RNxUM6uiyoWrXBZfGmZyL2 gb1zEZjWcSSCFd+NWg1/BYhZ5jeEptXNin1ZAM6seg38Angccj8YOPtyzxOx/hDFrb Q+ePr/t98/fHq2BcSzJCThnFTNb50fVmlIrGfb3oMvB11ToZpH+p8R2mhaDk4/44dl uEHGVh6Q6Ih5iyFuN8+PasXijpXT1PXJm+5Rkla8PX5Glna1OAsFe3wre6CQl62oa4 RAr1Z2b44rKF067M11yaRPI56z2wMDur4vLyEnjrhgmaYzW5D9XQ8I+PJlbP887wDq NXSNNWLPWiTbQ== Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jeff Layton Cc: "Darrick J. Wong" , Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 72A06E743C4 for ; Thu, 28 Sep 2023 21:30:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/YB2UNre3Me06D8sR36N+d2DZnTt3qpSlOfM4euQqkg=; b=rvjxQGATXlz5Rp TbwTg+RT38TzPTiAEjzYcu7E7k+GfXAJCobYUE0y2E9EOA2wAshjXPv6UQ3zpaxiAP7QjYMD4ll0f 5MXoClBlbSQ8iYjKR/2gdTcbUM02XzOXdNt3wcE4CvBkI3RwPs0rR9CfYSt515trnPJbhc8ekce+X mvC8SDzxdtrzVNjhn40Ot4EVmVcky1FfhfCpzMqztr1qyi6cjdTvGN0sbwUfkkjGhZgnNmX92UNOX QJbNie0FhVUcanZILdb5MW7Fi4ZuHkr0AgvRbcJTdAYcjMcDe18MhyMlSWg7QbUsnIT6iD42fiPyh b8SevncQtpIHqJX9BrGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qlyaq-006iYC-1m; Thu, 28 Sep 2023 21:30:44 +0000 Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qlyam-006iVR-0A for linux-mtd@lists.infradead.org; Thu, 28 Sep 2023 21:30:43 +0000 Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQvsA021537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936425; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=NGPOVv6aP7Wgx4/k9ruqGjDYWmjUQVAfEL5fppG6yE2RNxUM6uiyoWrXBZfGmZyL2 gb1zEZjWcSSCFd+NWg1/BYhZ5jeEptXNin1ZAM6seg38Angccj8YOPtyzxOx/hDFrb Q+ePr/t98/fHq2BcSzJCThnFTNb50fVmlIrGfb3oMvB11ToZpH+p8R2mhaDk4/44dl uEHGVh6Q6Ih5iyFuN8+PasXijpXT1PXJm+5Rkla8PX5Glna1OAsFe3wre6CQl62oa4 RAr1Z2b44rKF067M11yaRPI56z2wMDur4vLyEnjrhgmaYzW5D9XQ8I+PJlbP887wDq NXSNNWLPWiTbQ== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Cc: "Darrick J. Wong" , Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Mattia Dongili , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Brad Warrum , Ritu Agarwal , Hans de Goede , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Mark Gross , Jiri Slaby , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Sterba , David Howells , Marc Dionne , Ian Kent , Luis de Bethencourt , Salah Triki , "Tigran A. Aivazian" , Chris Mason , Josef Bacik , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Joel Becker , Christoph Hellwig , Nicolas Pitre , "Rafael J . Wysocki" , Ard Biesheuvel , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Christoph Hellwig , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Mikulas Patocka , Mike Kravetz , Muchun Song , Jan Kara , David Woodhouse , Dave Kleikamp , Tejun Heo , Trond Myklebust , Anna Schumaker , Chuck Lever , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Ryusuke Konishi , Anton Altaparmakov , Konstantin Komarov , Mark Fasheh , Joseph Qi , Bob Copeland , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Iurii Zaikin , Tony Luck , "Guilherme G. Piccoli" , Anders Larsen , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Sergey Senozhatsky , Phillip Lougher , Steven Rostedt , Masami Hiramatsu , Evgeniy Dushistov , Chandan Babu R , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Hugh Dickins , Andrew Morton , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , 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 , 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 Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230928_143040_248981_DCB7C09D X-CRM114-Status: GOOD ( 23.31 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3E189E728C2 for ; Fri, 29 Sep 2023 15:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0/8ulbJKNu2T4SBrsBeBbdbR1+IVBJiwNhPmGn8rXHA=; b=gHuA6qYVausY7t whJxPfDTKx5tiptBiKtPL6C+QD4NweyYJ7wrb7j9/6oo/Lr6UJOJC9lGvC1c7ielZa5u2QeqQ5RVa 4UbrgPTuD7SXahYnVz8yjVuCXG54EJZ83y8Bl4EE3+7NUxFG9gwKa8jbxakrezEh2nhkllponb1Ie dWIxYu96bQk4FNeZBZjpqA1s1LR9HbscuC0LEPXa/T1BOHwjmdbuzh/sV+Ieksxtn4bo+LUpD+uYn avvVp5q2qMtsUZ1/E9bd/mAgMjAoKX+juqYqfAG20Mt0Y45Kf4Z1iTu9O46upADxJbNrBJCh+oLiC Jc2rfL+LraonuF6clF/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qmFXi-008CZy-2p; Fri, 29 Sep 2023 15:36:38 +0000 Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qlyap-006iVR-1P for linux-um@lists.infradead.org; Thu, 28 Sep 2023 21:30:45 +0000 Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQvsA021537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936425; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=NGPOVv6aP7Wgx4/k9ruqGjDYWmjUQVAfEL5fppG6yE2RNxUM6uiyoWrXBZfGmZyL2 gb1zEZjWcSSCFd+NWg1/BYhZ5jeEptXNin1ZAM6seg38Angccj8YOPtyzxOx/hDFrb Q+ePr/t98/fHq2BcSzJCThnFTNb50fVmlIrGfb3oMvB11ToZpH+p8R2mhaDk4/44dl uEHGVh6Q6Ih5iyFuN8+PasXijpXT1PXJm+5Rkla8PX5Glna1OAsFe3wre6CQl62oa4 RAr1Z2b44rKF067M11yaRPI56z2wMDur4vLyEnjrhgmaYzW5D9XQ8I+PJlbP887wDq NXSNNWLPWiTbQ== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Cc: "Darrick J. Wong" , Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Mattia Dongili , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Brad Warrum , Ritu Agarwal , Hans de Goede , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Mark Gross , Jiri Slaby , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Sterba , David Howells , Marc Dionne , Ian Kent , Luis de Bethencourt , Salah Triki , "Tigran A. Aivazian" , Chris Mason , Josef Bacik , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Joel Becker , Christoph Hellwig , Nicolas Pitre , "Rafael J . Wysocki" , Ard Biesheuvel , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Christoph Hellwig , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Mikulas Patocka , Mike Kravetz , Muchun Song , Jan Kara , David Woodhouse , Dave Kleikamp , Tejun Heo , Trond Myklebust , Anna Schumaker , Chuck Lever , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Ryusuke Konishi , Anton Altaparmakov , Konstantin Komarov , Mark Fasheh , Joseph Qi , Bob Copeland , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Iurii Zaikin , Tony Luck , "Guilherme G. Piccoli" , Anders Larsen , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Sergey Senozhatsky , Phillip Lougher , Steven Rostedt , Masami Hiramatsu , Evgeniy Dushistov , Chandan Babu R , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Hugh Dickins , Andrew Morton , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , 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 , 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 Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230928_143043_631718_3530938E X-CRM114-Status: GOOD ( 22.98 ) X-Mailman-Approved-At: Fri, 29 Sep 2023 08:36:32 -0700 X-BeenThere: linux-um@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+linux-um=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AB8CFE743D6 for ; Fri, 29 Sep 2023 00:40:52 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=WaP79h5b; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RxWjb2h90z3fPm for ; Fri, 29 Sep 2023 10:40:51 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=WaP79h5b; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=mit.edu (client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver=lists.ozlabs.org) X-Greylist: delayed 740 seconds by postgrey-1.37 at boromir; Fri, 29 Sep 2023 07:39:44 AEST Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RxRhc5MRLz3cCS for ; Fri, 29 Sep 2023 07:39:42 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-111-87.bstnma.fios.verizon.net [173.48.111.87]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 38SLQv6B021535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Sep 2023 17:26:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1695936431; bh=w4hql40FuyyfsTNK9D530X9ExV2y5b7TU7/1a0HHsnU=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=WaP79h5bQ62LFZ7vHHOCmGWKrdVEw7kTPaoOfwjqG7743/KpOeTQfqQpPAFra25uw qHhUQptGls8wmshhyjdnO9G7FinJGRSu/H+Pr36/HOeVsY2L1QKwp6wJYXWDQj3sU6 spxP8X5T3MP/kvZK7FBaCvSP9XyEeM6QQ1hm7OJdJzn5aY8Xu6Fua+baunPXgUoy7L KhVrZIKyvYcsT0NIC33rKKlIWvn/ApA3rOkeZe9sao19Z+JDKma1IeqPjZOBPScT5p +jnf6c81JzZ84Oc7GpEzLi5aGjfgb8lOPxXH2Up3ynLvwNxgs1A65KPgjW+ME/+Top l7dosLTQv306w== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 06AD715C0266; Thu, 28 Sep 2023 17:26:57 -0400 (EDT) Date: Thu, 28 Sep 2023 17:26:56 -0400 From: "Theodore Ts'o" To: Jeff Layton Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Message-ID: <20230928212656.GC189345@mit.edu> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> X-Mailman-Approved-At: Fri, 29 Sep 2023 10:31:49 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Konstantin Komarov , "Rafael J . Wysocki" , "Darrick J. Wong" , Anders Larsen , Carlos Llamas , Andrii Nakryiko , Mattia Dongili , Hugh Dickins , Yonghong Song , Alexander Gordeev , Christoph Hellwig , Mike Marshall , Paulo Alcantara , linux-xfs@vger.kernel.org, James Morris , Christoph Hellwig , Christian Borntraeger , devel@lists.orangefs.org, Shyam Prasad N , linux-um@lists.infradead.org, Nicholas Piggin , Alexander Viro , Eric Van Hensbergen , Suren Baghdasaryan , Trond Myklebust , Anton Altaparmakov , Christian Brauner , Greg Kroah-Hartman , Stephen Smalley , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Sergey Senozhatsky , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Chuck Lever , Sven Schnelle , Jiri Olsa , Jan Kara , Tejun Heo , Andrew Morton , linux-trace-kernel@vger.kernel.org, Linus Torvalds , Dave Kleikamp , linux-mm@kvack.org, Joel Fernandes , Eric Dumazet , Stanislav Fomichev , codalist@telemann.coda.cs.cmu.edu, linux-s390@vger.kernel.org, linux-nilfs@vger.kernel.org, Paul Moore , Leon Romanovsky , John Fastabend , Luis Chamberlain , Iurii Zaikin , Namjae Jeon , Masami Hiramatsu , Todd Kjos , Vasily Gorbik , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org, Miklos Szeredi , John Johansen , Jaegeuk Kim , Martijn Coenen , OGAWA Hirofumi , Hao Luo , Tony Luck , Nicolas Pitre , linux-ntfs-dev@lists.sourceforge.net, Muchun Song , linux-f2fs-devel@lists.sourceforge.net, "Guilherme G. Piccoli" , gfs2@lists.linux.dev, "Eric W. Biederman" , Anna Schumaker , Brad Warrum , Mike Kravetz , linux-efi@vger. kernel.org, Martin Brandenburg , ocfs2-devel@lists.linux.dev, Alexei Starovoitov , Yue Hu , Chris Mason , linux-mtd@lists.infradead.org, linux-hardening@vger.kernel.org, Marc Dionne , Jiri Slaby , linux-afs@lists.infradead.org, Ian Kent , Naohiro Aota , Daniel Borkmann , Dennis Dalessandro , linux-rdma@vger.kernel.org, coda@cs.cmu.edu, Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Ilya Dryomov , Paolo Abeni , "Serge E. Hallyn" , Christian Schoenebeck , Kees Cook , Arnd Bergmann , autofs@vger.kernel.org, Steven Rostedt , Mark Gross , Damien Le Moal , Eric Paris , ceph-devel@vger.kernel.org, Gao Xiang , Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Olga Kornievskaia , Song Liu , samba-technical@lists.samba.org, Steve French , Jeremy Kerr , Netdev , Bob Peterson , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, ntfs3@lists.linux.dev, linux-erofs@lists.ozlabs.org, "David S . Miller" , Chandan Babu R , jfs-discussion@lists.sourceforge.net, Jan Kara , Neil Brown , Dominique Martinet , Amir Goldstein , Bob Copeland , KP Singh , linux-unionfs@vger.kernel.org, David Howells , Joseph Qi , Andreas Dilger , M ikulas Patocka , Ard Biesheuvel , Anton Ivanov , Andreas Gruenbacher , Richard Weinberger , Mark Fasheh , Dai Ngo , Jason Gunthorpe , linux-serial@vger.kernel.org, Jakub Kicinski , Salah Triki , platform-driver-x86@vger.kernel.org, Evgeniy Dushistov , linux-cifs@vger.kernel.org, Heiko Carstens , Chao Yu , apparmor@lists.ubuntu.com, Josef Bacik , Tom Talpey , Hans de Goede , "Tigran A. Aivazian" , David Sterba , Xiubo Li , Ryusuke Konishi , Johannes Thumshirn , Ritu Agarwal , Luis de Bethencourt , Martin KaFai Lau , v9fs@lists.linux.dev, David Sterba , linux-security-module@vger.kernel.org, Jeffle Xu , Phillip Lougher , Johannes Berg , Sungjong Seo , David Woodhouse , linux-karma-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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