From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:46602 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750704AbeBBFet (ORCPT ); Fri, 2 Feb 2018 00:34:49 -0500 Message-ID: <1517549681.3222.12.camel@HansenPartnership.com> Subject: Re: [Lsf-pc] [LSF/MM TOPIC] fs-verity: file system-level integrity protection From: James Bottomley To: Andreas Dilger , Dave Chinner Cc: Theodore Ts'o , Mimi Zohar , linux-fsdevel , lsf-pc@lists.linux-foundation.org Date: Fri, 02 Feb 2018 06:34:41 +0100 In-Reply-To: References: <1517197150.29187.457.camel@linux.vnet.ibm.com> <20180129045012.GB9516@thunk.org> <1517227741.29187.515.camel@linux.vnet.ibm.com> <20180129230209.GA30762@thunk.org> <1517354702.3469.60.camel@linux.vnet.ibm.com> <20180131160510.GA18615@thunk.org> <1517418768.3937.59.camel@HansenPartnership.com> <20180131184647.GA29819@thunk.org> <1517431273.3344.28.camel@HansenPartnership.com> <20180201000315.GB3375@thunk.org> <20180201230415.7cyxhwq234vd3in4@destitution> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-eVrvLgOFsvW2BZSSPQHJ" Mime-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-eVrvLgOFsvW2BZSSPQHJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2018-02-01 at 16:43 -0700, Andreas Dilger wrote: > On Feb 1, 2018, at 4:04 PM, Dave Chinner wrote: > >=20 > >=20 > > On Wed, Jan 31, 2018 at 07:03:16PM -0500, Theodore Ts'o wrote: > > >=20 > > > On Wed, Jan 31, 2018 at 12:41:13PM -0800, James Bottomley wrote: > > > >=20 > > > > >=20 > > > > > Like fscrypto, where most of the code is in fs/crypto, most > > > > > of the fs-verity will be in fs/verity.=C2=A0=C2=A0There will be m= inimal > > > > > hooks in a particular file system, so if another file system > > > > > wants to play, then can do so relatively easily. > > > >=20 > > > > OK, sounds good ... I notice, now I look, that fscrypt uses > > > > xattrs (albeit hidden under the covers of get/set_context), > > > > will dm-verity use the same trick or do people really need > > > > space in the inode? > > >=20 > > > I assume you mean fs-verity above, and no, we aren't going to use > > > xattrs because the Merkle tree won't fit in the xattr.=C2=A0=C2=A0So = the > > > plan was to put the fs-verity header, the PKCS7 signature, and > > > the Merkle tree after i_size (rounded to a blocksize > > > boundary).=C2=A0=C2=A0Remember, the fs-verity case we only worry abou= t the > > > read-ony case. > >=20 > > I think putting valid data beyond EOF is going to be problematic > > for many filesystems. Getting things like truncate right are hard > > enough without having to special case a bunch of new functionality > > that specifically allows IO access beyond EOF. Indeed, how does > > "truncate isize but leave special data behind" work and what's the > > userspace API to drive it? And how does it interact with all the > > page cache code that checks for page->index beyond EOF to detect a > > truncated page that should not be accessed? > >=20 > > There's also further complications for filesystems like XFS e.g. > > how do we tell the difference between valid data beyond EOF and > > speculative allocation (done by delalloc) beyond EOF that contains > > no data and can be removed if it is not written to in a short > > while? > >=20 > > This just seems like a horrible can of worms to me and is not > > something we should be building generic infrastructure around. > >=20 > > Just how big do these merkle trees get, anyway? >=20 > The Merkle tree will have one checksum per "leaf block" of the > filesystem (though I'd recommend to use a fixed-size checksum leaf > block like 4KB so that userspace doesn't need to care about the > actual filesystem blocksize on disk).=C2=A0=C2=A0After that, there is a t= ree of > checksums from the leaf blocks up to the root.=C2=A0=C2=A0If there was a = weak > checksum like CRC32 (4 bytes/leaf) then the tree size would be > somewhat over 0.1% of the file size.=C2=A0=C2=A0If the tree has a strong > checksum like SHA256 (32 bytes/leaf) then the overhead is over 0.8%. Actually, based on what Ted has already said about his use case, I don't believe we need a binary merkle tree. =C2=A0The binary tree itself is only useful if you're doing partial hash verifications on random chunks as you download, like in p2p. =C2=A0In this use case we only verify the lea= f nodes on read and the signature is only verified at open, so it sounds like all we actually need is the leaf chunks and a signature over the hash of all of them, in fact a simple hash list. =C2=A0That also protects u= s from having to worry about pre-image attacks which are a known problem of binary merkle trees. Of course, the leaf nodes are sill about 50% of the binary tree size, so I've only made a small space improvement. James --=-eVrvLgOFsvW2BZSSPQHJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iHUEABMIAB0WIQTnYEDbdso9F2cI+arnQslM7pishQUCWnP4cQAKCRDnQslM7pis hSFbAQDezR7Rw1bVvLCt18GvJAnmGUvtDt494zrSwyYNjNPaQgD/dqSGSR01aQJB OIYNO1DksCA3m6f16pjhd439VoaDhXw= =xsb6 -----END PGP SIGNATURE----- --=-eVrvLgOFsvW2BZSSPQHJ--