From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f47.google.com ([209.85.214.47]:37361 "EHLO mail-it0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751604AbeA2VVw (ORCPT ); Mon, 29 Jan 2018 16:21:52 -0500 Received: by mail-it0-f47.google.com with SMTP id h129so4741815ita.2 for ; Mon, 29 Jan 2018 13:21:52 -0800 (PST) From: Andreas Dilger Message-Id: <9599F14B-ED89-414F-83D1-D5D09FD8AE62@dilger.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_EAD1C42B-379C-4DDC-8ADF-D974C8B7EED5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Lsf-pc] [LSF/MM TOPIC] fs-verity: file system-level integrity protection Date: Mon, 29 Jan 2018 14:21:56 -0700 In-Reply-To: <20180129010321.GB29839@thunk.org> Cc: James Bottomley , linux-fsdevel , lsf-pc@lists.linux-foundation.org To: Theodore Ts'o References: <1516942235.4082.52.camel@HansenPartnership.com> <20180126145856.GA2841@thunk.org> <1516985067.4000.10.camel@HansenPartnership.com> <20180126215540.GA23308@thunk.org> <275E5E86-635E-4D79-9AC9-3D24318EDDDF@dilger.ca> <1517069959.3012.13.camel@HansenPartnership.com> <20180128024604.GA12320@thunk.org> <1517162590.3082.55.camel@HansenPartnership.com> <20180128214925.GA13621@thunk.org> <1517185319.3082.92.camel@HansenPartnership.com> <20180129010321.GB29839@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Apple-Mail=_EAD1C42B-379C-4DDC-8ADF-D974C8B7EED5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jan 28, 2018, at 6:03 PM, Theodore Ts'o wrote: > > So if there as a solution which enapculated the information needed to > create the fs-verity header and the PKCS7 signature in an xattr --- > which is how you carry it around in the tar image --- and when the > tarfile is unpacked, the software which does the unpacking calls a > library which checks for the xattr, removes it, writes out the > fsverity header and Merkle tree, and then calls the ioctl which sets > the "verity" bit, thus instantiating the data integrity protection, > would this meet your requirements? > > In other words, the xattr in the tar file is just the method for > carrying the information; and (a) it is not how the information would > be stored in the underlying file system when it is actually used, and > (b) it requires the userspace code to do this transformation, so we > don't have to build the Merkle tree in the kernel. Is this sufficient > for your container use case? Why would you throw away the xattr signature at that point? That would still be useful to store back into a new tarball or other backup of the file, and is also useful for external tools to verify (e.g. bittorrent, maybe rsync or others in the future), especially if it is a common format. That doesn't mean storing the whole fs-verity tree in an xattr (though that could also be done with the ext4 xattr inode feature), nor does it imply that this is a "magic" xattr that causes the fs-verity tree to be created when written. It would just be an xattr that stores the top-level hash of the Merkle tree to expose to userspace. Also, the Merkle tree should be computed with fixed-size leaf blocks like 1KB or 4KB, so that userspace doesn't need to know details like the underlying fs blocksize. The actual on-disk fs-verity tree can be stored in fs blocksize units, and if the blocksize is larger than the leaf blocks it would just store a higher-level node in the Merkle tree. We actually worked on a design for this years ago with Lustre+ZFS, with sending higher-level nodes in the Merkle tree over the network for the RPC checksum so that it is independent of the client/server PAGE_SIZE, the RPC size and the underlying fs blocksize, but this would also be useful for storage in tarballs or for read/write requests with fs-verity. For more details see: http://wiki.old.lustre.org/images/c/c1/End-to-End-Integrity-2009-06-15.pdf Cheers, Andreas --Apple-Mail=_EAD1C42B-379C-4DDC-8ADF-D974C8B7EED5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAlpvkHUACgkQcqXauRfM H+AMvw/+KxwSZr8OX3M8SY08RSVBoxvr1PK0qMO8loR8HJLisbFx4GPpLJ8gJFCd hK82zT7a0WFc4ix+Qu0lhyXjKV+hgc7cAhKiEiUtP2QDnGoNMxi0Y93QZfJEtHiz QQP/oxKNI1bX3ebtKzbXfudDClkY5h8HhHldAjrQTihF2kviWFXkn4cPw4fHMg0V TVimyaERKxyvP+BdGnX+4+3DYQHNc5ICwJNrE+nc0lz3FuNdSU6meT1tyOMUOdb8 eOx1aX8yh9rCPMlW76jwOwRxeBok2opOWcju6bRD6YIqjSYUpsNXcEC4M+/CV2/Y 9++VHHDWb3v/oth6KtVv0baAAU17B5rbGDjdvUqjlRAtj4R/n1INK/4yUL5bQbee EgHQiA3kXu4zhqG43tspXjb+WVJzosg/LL4wg/GQnIpn95a+xmigGbN6Y/VO4Isn zKF83hVTHxXlVmog6BI25oqgDJauLo//TpjKi4DspT0WaJMjPCNMvcD6FgzwBuSI z7bBaJe+CF+wCDh8dqnIZ9+FPprD+nGlYNWbCClmC5uBeF+43MOlouke/bydH13s 0u4df2FED+NFnutB9xQC8z/e1gTeNxYSARLpxM/+nb6qe8h+eMsmRblg/8jlAPtA R8fwssMI5SRdzIf6LnEPNG8KEyn26nLgUzW5a1FbY069yxW8VNE= =NX7C -----END PGP SIGNATURE----- --Apple-Mail=_EAD1C42B-379C-4DDC-8ADF-D974C8B7EED5--