On Thu, Jun 06, 2019 at 08:51:50AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
>
> Add a documentation file for fs-verity, covering....
>
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
Looks good; you can add:
Reviewed-by: Theodore Ts'o <tytso@xxxxxxx>
One minor design point below:
> +ext4 stores the verity metadata (Merkle tree and fsverity_descriptor)
> +past the end of the file, starting at the first page fully beyond
^^^^
> +i_size. This approach works because (a) verity files are readonly,
> +and (b) pages fully beyond i_size aren't visible to userspace but can
> +be read/written internally by ext4 with only some relatively small
> +changes to ext4. This approach avoids having to depend on the
> +EA_INODE feature and on rearchitecturing ext4's xattr support to
> +support paging multi-gigabyte xattrs into memory, and to support
> +encrypting xattrs. Note that the verity metadata *must* be encrypted
> +when the file is, since it contains hashes of the plaintext data.
If we ever want to support mounting, say, a file system with 4k blocks
and fsverity enabled on a architecture with a 16k or 64k page size,
then "page" in that first sentence will need to become "block". At
the moment we only support fsverity when page size == block size, so
it's not an issue.
However, it's worth reflecting on what this means. In order to
satisfy this requirement (from the mmap man page):
A file is mapped in multiples of the page size. For a file
that is not a multiple of the page size, the remaining memory
is zeroed when mapped...
we're going to have to special case how the last page gets mmaped.
The simplest way to do this will be to map in an anonymous page which
just has the blocks that are part of the data block copied in, and the
rest of the page can be zero'ed.
One thing we might consider doing just to make life much easier for
ourselves (should we ever want to support page size != block size ---
which I could imagine some folks like Chandan might find desirable) is
to specify that the fsverity metadata begins at an offset which begins
at i_size rounded up to the next 64k binary, which should handle all
current and future architectures' page sizes.
- Ted
