On Thu, Jan 25, 2018 at 04:47:46PM -0800, James Bottomley wrote: > > How do you know the file is in this special format? Would it be a per > filesystem flag (so every file) or selectable per-file by some other > mechanism. If it's per-file, why not simply use the existing xattr > mechanism? It would be using a per-file flag, just like we do with fscrypt. Given that we only need a single bit of information, using an xattr would be a inefficeint. > > *) The pages are verified as they are read, so pages are verified as > > they are read the storage device; this avoids a large latency hit > > when the file is first opened or referenced. > > The cost of this is presumably one hash per page in the tree, so it > costs quite a bit in terms of space. Presumably the hash tree is also > dynamically resident meaning a page fault could now also potentially > fault in the hash tree, leading to a lot of sub optimal I/O patterns? This is how dm-verity works, which is used on every single modern Chrome OS and Android phone, with no complaints. (It doesn't work that way on your phone, unless you've upgraded. :-) > > *) The design and code are done by file system developers, so it > > doesn't have the locking problems of the IMA code. > > That's a bit unfair. My next question was going to be why not just > make this an actual IMA mode (meaning you could choose to have a global > hash or a tree hash). Does this mean that a-priori you've already > ruled out IMA integration because you don't want to work with the > developers? IMA has a lot of complexity, which I would rather not drag in as a dependency. Also, having seen some of the ah, "discussions" that Christoph and Dave Chinner have been having with the IMA folks, I'd rather not taint this proposal with IMA's reputation. :-) I am completely open to an optional integration with IMA, but I would prefer not to require CONFIG_IMA to be enabled in order to use fs-verity. > PKCS11 is the standard for cryptokeys. I presume you just mean a > message signing standard like PKCS7 or RFC 2315? Sorry, I meant PKCS7. It would be a restricted PKCS7 mode, using a detached signature. My plan was to reuse the existing code we already have written for signed kernel modules. > > Most of this feature could also be used with a non-cryptographic > > checksum to provide data checksums for read-only files in a general > > way for all file systems. It wouldn't be as flexible as btrfs, but > > for files being stored for backup purposes, it should work quite > > well. > > I assume the "write" part of this is that the file must be deleted and > re-created? I'm not sure what you mean. If you have an existing file that you want to protect using fs-verity, it's a matter of appending the fs-verity information onto the end of the file, and then setting the fs-verity flag, at which point all of the fs-verity information disappears from the perspective of stat(2) and read(2) system calls. The verity bit can be examined using FS_IOC_GETFLAGS, and more details about which key was used to sign the file could be examined via some ioctl interface. In general, though, it's expected that userspace won't care about such details. Any reads that don't verify will return an error, and if the key used to sign fs-verity information is not trusted by the kernel, the open will return an error. So all userspace or a security policy would need to take of is that file does have the verity bit set. Cheers, - Ted
