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
| ||
|
Date: Thu, 24 Jan 2019 16:32:17 -0800 From: Matthew Wilcox <willy@...radead.org> To: "Theodore Y. Ts'o" <tytso@....edu> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@...radead.org>, "Darrick J. Wong" <darrick.wong@...cle.com>, Eric Biggers <ebiggers@...nel.org>, linux-fscrypt@...r.kernel.org, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net Subject: Re: Proposal: A new fs-verity interface On Thu, Jan 24, 2019 at 06:22:37PM -0500, Theodore Y. Ts'o wrote: > The main issue is that for a 129 MB file, the Merkle data is going to > be a Megabyte. 127MB ... I pointed out this error the last time the documentation was posted. > We could store the metadata somewhere else --- for example, we could > store it in another inode. But inodes have overhead, and that would > mean using two inodes for every fs-verity protected files --- and we > don't need all of the other metadata (mtime, ctime, etc.) for the > Merkle tree. So that's how we got to where we were. I think the > approach of storing it using the same extent tree where we map logical > block numbers to physical block numbers make a lot of sense for ext4 > and f2fs. > > It seems that some file system (which may never even implement > fs-verity) their developers hate that particular approach. So that's > where the suggestion of using a separate file descriptor to convey the > Merkle tree data to the file system came from. It wasn't my first > choice. I'll reiterate an API I suggested on December 21st: : verity_fd = ioctl(fd, FS_IOC_VERITY_FD); : write(verity_fd, &merkle_tree); : close(verity_fd); : : At final close of that verity_fd, the filesystem behaves in the same way : that it does on receipt of this FS_IOC_ENABLE_VERITY ioctl today.
Powered by blists - more mailing lists