29 Dec, 2020

1 commit

  • Embedding the file path inside kernel source code files isn't
    particularly useful as often files are moved around and the paths become
    incorrect. checkpatch.pl warns about this since v5.10-rc1.

    Acked-by: Luca Boccassi
    Link: https://lore.kernel.org/r/20201113211918.71883-2-ebiggers@kernel.org
    Signed-off-by: Eric Biggers

    Eric Biggers
     

13 May, 2020

1 commit

  • Fix all kerneldoc warnings in fs/verity/ and include/linux/fsverity.h.
    Most of these were due to missing documentation for function parameters.

    Detected with:

    scripts/kernel-doc -v -none fs/verity/*.{c,h} include/linux/fsverity.h

    This cleanup makes it possible to check new patches for kerneldoc
    warnings without having to filter out all the existing ones.

    Link: https://lore.kernel.org/r/20200511192118.71427-2-ebiggers@kernel.org
    Signed-off-by: Eric Biggers

    Eric Biggers
     

15 Jan, 2020

2 commits

  • When initializing an fs-verity hash algorithm, also initialize a mempool
    that contains a single preallocated hash request object. Then replace
    the direct calls to ahash_request_alloc() and ahash_request_free() with
    allocating and freeing from this mempool.

    This eliminates the possibility of the allocation failing, which is
    desirable for the I/O path.

    This doesn't cause deadlocks because there's no case where multiple hash
    requests are needed at a time to make forward progress.

    Link: https://lore.kernel.org/r/20191231175545.20709-1-ebiggers@kernel.org
    Reviewed-by: Theodore Ts'o
    Signed-off-by: Eric Biggers

    Eric Biggers
     
  • When fs-verity verifies data pages, currently it reads each Merkle tree
    page synchronously using read_mapping_page().

    Therefore, when the Merkle tree pages aren't already cached, fs-verity
    causes an extra 4 KiB I/O request for every 512 KiB of data (assuming
    that the Merkle tree uses SHA-256 and 4 KiB blocks). This results in
    more I/O requests and performance loss than is strictly necessary.

    Therefore, implement readahead of the Merkle tree pages.

    For simplicity, we take advantage of the fact that the kernel already
    does readahead of the file's *data*, just like it does for any other
    file. Due to this, we don't really need a separate readahead state
    (struct file_ra_state) just for the Merkle tree, but rather we just need
    to piggy-back on the existing data readahead requests.

    We also only really need to bother with the first level of the Merkle
    tree, since the usual fan-out factor is 128, so normally over 99% of
    Merkle tree I/O requests are for the first level.

    Therefore, make fsverity_verify_bio() enable readahead of the first
    Merkle tree level, for up to 1/4 the number of pages in the bio, when it
    sees that the REQ_RAHEAD flag is set on the bio. The readahead size is
    then passed down to ->read_merkle_tree_page() for the filesystem to
    (optionally) implement if it sees that the requested page is uncached.

    While we're at it, also make build_merkle_tree_level() set the Merkle
    tree readahead size, since it's easy to do there.

    However, for now don't set the readahead size in fsverity_verify_page(),
    since currently it's only used to verify holes on ext4 and f2fs, and it
    would need parameters added to know how much to read ahead.

    This patch significantly improves fs-verity sequential read performance.
    Some quick benchmarks with 'cat'-ing a 250MB file after dropping caches:

    On an ARM64 phone (using sha256-ce):
    Before: 217 MB/s
    After: 263 MB/s
    (compare to sha256sum of non-verity file: 357 MB/s)

    In an x86_64 VM (using sha256-avx2):
    Before: 173 MB/s
    After: 215 MB/s
    (compare to sha256sum of non-verity file: 223 MB/s)

    Link: https://lore.kernel.org/r/20200106205533.137005-1-ebiggers@kernel.org
    Reviewed-by: Theodore Ts'o
    Signed-off-by: Eric Biggers

    Eric Biggers
     

13 Aug, 2019

1 commit

  • To meet some users' needs, add optional support for having fs-verity
    handle a portion of the authentication policy in the kernel. An
    ".fs-verity" keyring is created to which X.509 certificates can be
    added; then a sysctl 'fs.verity.require_signatures' can be set to cause
    the kernel to enforce that all fs-verity files contain a signature of
    their file measurement by a key in this keyring.

    See the "Built-in signature verification" section of
    Documentation/filesystems/fsverity.rst for the full documentation.

    Reviewed-by: Theodore Ts'o
    Signed-off-by: Eric Biggers

    Eric Biggers
     

29 Jul, 2019

1 commit

  • Add functions that verify data pages that have been read from a
    fs-verity file, against that file's Merkle tree. These will be called
    from filesystems' ->readpage() and ->readpages() methods.

    Since data verification can block, a workqueue is provided for these
    methods to enqueue verification work from their bio completion callback.

    See the "Verifying data" section of
    Documentation/filesystems/fsverity.rst for more information.

    Reviewed-by: Theodore Ts'o
    Reviewed-by: Jaegeuk Kim
    Signed-off-by: Eric Biggers

    Eric Biggers