<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/fsverity.h, branch v6.19.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-08-21T11:58:08+00:00</updated>
<entry>
<title>fsverity: check IS_VERITY() in fsverity_cleanup_inode()</title>
<updated>2025-08-21T11:58:08+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2025-08-10T07:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a3d00dde63a339d31d1fdeead24ddfd4d459c70'/>
<id>urn:sha1:8a3d00dde63a339d31d1fdeead24ddfd4d459c70</id>
<content type='text'>
Since getting the address of the fsverity_info has gotten a bit more
expensive, make fsverity_cleanup_inode() check for IS_VERITY() instead.
This avoids adding more overhead to non-verity files.

This assumes that verity info is never set when !IS_VERITY(), which is
currently true, but add a VFS_WARN_ON_ONCE() that asserts that.  (This
of course defeats the optimization, but only when CONFIG_VFS_DEBUG=y.)

Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Link: https://lore.kernel.org/20250810075706.172910-14-ebiggers@kernel.org
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: remove inode::i_verity_info</title>
<updated>2025-08-21T11:58:08+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2025-08-10T07:57:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=818c659ac164e4e4639ceaedaccbdfebb1ef63b5'/>
<id>urn:sha1:818c659ac164e4e4639ceaedaccbdfebb1ef63b5</id>
<content type='text'>
Now that all fsverity-capable filesystems store the pointer to
fsverity_info in the filesystem-specific part of the inode structure,
inode::i_verity_info is no longer needed.  Update fsverity_info_addr()
to no longer support the fallback to inode::i_verity_info.  Finally,
remove inode::i_verity_info itself, and move the forward declaration of
struct fsverity_info from fs.h (which no longer needs it) to fsverity.h.

The end result of the migration to the filesystem-specific pointer is
memory savings on CONFIG_FS_VERITY=y kernels for all filesystems that
don't support fsverity.  Specifically, their in-memory inodes are now
smaller by the size of a pointer: either 4 or 8 bytes.

Co-developed-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Link: https://lore.kernel.org/20250810075706.172910-13-ebiggers@kernel.org
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsverity: add support for info in fs-specific part of inode</title>
<updated>2025-08-21T11:58:07+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2025-08-10T07:57:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2a7349add18e5915cd87251af5f98db1772b6131'/>
<id>urn:sha1:2a7349add18e5915cd87251af5f98db1772b6131</id>
<content type='text'>
Add an inode_info_offs field to struct fsverity_operations, and update
fs/verity/ to support it.  When set to a nonzero value, it specifies the
offset to the fsverity_info pointer within the filesystem-specific part
of the inode structure, to be used instead of inode::i_verity_info.

Since this makes inode::i_verity_info no longer necessarily used, update
comments that mentioned it.

This is a prerequisite for a later commit that removes
inode::i_verity_info, saving memory and improving cache efficiency on
filesystems that don't support fsverity.

Co-developed-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Link: https://lore.kernel.org/20250810075706.172910-9-ebiggers@kernel.org
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsverity: rework fsverity_get_digest() again</title>
<updated>2023-06-14T17:41:07+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2023-06-12T19:00:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74836ecbc5c7565d24a770917644e96af3e98d25'/>
<id>urn:sha1:74836ecbc5c7565d24a770917644e96af3e98d25</id>
<content type='text'>
Address several issues with the calling convention and documentation of
fsverity_get_digest():

- Make it provide the hash algorithm as either a FS_VERITY_HASH_ALG_*
  value or HASH_ALGO_* value, at the caller's choice, rather than only a
  HASH_ALGO_* value as it did before.  This allows callers to work with
  the fsverity native algorithm numbers if they want to.  HASH_ALGO_* is
  what IMA uses, but other users (e.g. overlayfs) should use
  FS_VERITY_HASH_ALG_* to match fsverity-utils and the fsverity UAPI.

- Make it return the digest size so that it doesn't need to be looked up
  separately.  Use the return value for this, since 0 works nicely for
  the "file doesn't have fsverity enabled" case.  This also makes it
  clear that no other errors are possible.

- Rename the 'digest' parameter to 'raw_digest' and clearly document
  that it is only useful in combination with the algorithm ID.  This
  hopefully clears up a point of confusion.

- Export it to modules, since overlayfs will need it for checking the
  fsverity digests of lowerdata files
  (https://lore.kernel.org/r/dd294a44e8f401e6b5140029d8355f88748cd8fd.1686565330.git.alexl@redhat.com).

Acked-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt; # for the IMA piece
Link: https://lore.kernel.org/r/20230612190047.59755-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
</content>
</entry>
<entry>
<title>fsverity: use WARN_ON_ONCE instead of WARN_ON</title>
<updated>2023-04-12T02:23:15+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2023-03-28T04:03:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8eb8af4b3df5965dc65a24a32768043f39d82d59'/>
<id>urn:sha1:8eb8af4b3df5965dc65a24a32768043f39d82d59</id>
<content type='text'>
As per Linus's suggestion
(https://lore.kernel.org/r/CAHk-=whefxRGyNGzCzG6BVeM=5vnvgb-XhSeFJVxJyAxAF8XRA@mail.gmail.com),
use WARN_ON_ONCE instead of WARN_ON.  This barely adds any extra
overhead, and it makes it so that if any of these ever becomes reachable
(they shouldn't, but that's the point), the logs can't be flooded.

Link: https://lore.kernel.org/r/20230406181542.38894-1-ebiggers@kernel.org
Reviewed-by: Chaitanya Kulkarni &lt;kch@nvidia.com&gt;
Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
</content>
</entry>
<entry>
<title>fsverity: support verifying data from large folios</title>
<updated>2023-01-27T22:46:31+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2023-01-27T22:15:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d0f0e57ed900917836385527ce5b122fa1425a3'/>
<id>urn:sha1:5d0f0e57ed900917836385527ce5b122fa1425a3</id>
<content type='text'>
Try to make fs/verity/verify.c aware of large folios.  This includes
making fsverity_verify_bio() support the case where the bio contains
large folios, and adding a function fsverity_verify_folio() which is the
equivalent of fsverity_verify_page().

There's no way to actually test this with large folios yet, but I've
tested that this doesn't cause any regressions.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Link: https://lore.kernel.org/r/20230127221529.299560-1-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fsverity: support enabling with tree block size &lt; PAGE_SIZE</title>
<updated>2023-01-10T03:06:06+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-12-23T20:36:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=56124d6c87fd749477425110d2564166621a89c4'/>
<id>urn:sha1:56124d6c87fd749477425110d2564166621a89c4</id>
<content type='text'>
Make FS_IOC_ENABLE_VERITY support values of
fsverity_enable_arg::block_size other than PAGE_SIZE.

To make this possible, rework build_merkle_tree(), which was reading
data and hash pages from the file and assuming that they were the same
thing as "blocks".

For reading the data blocks, just replace the direct pagecache access
with __kernel_read(), to naturally read one block at a time.

(A disadvantage of the above is that we lose the two optimizations of
hashing the pagecache pages in-place and forcing the maximum readahead.
That shouldn't be very important, though.)

The hash block reads are a bit more difficult to handle, as the only way
to do them is through fsverity_operations::read_merkle_tree_page().

Instead, let's switch to the single-pass tree construction algorithm
that fsverity-utils uses.  This eliminates the need to read back any
hash blocks while the tree is being built, at the small cost of an extra
block-sized memory buffer per Merkle tree level.  This is probably what
I should have done originally.

Taken together, the above two changes result in page-size independent
code that is also a bit simpler than what we had before.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Andrey Albershteyn &lt;aalbersh@redhat.com&gt;
Tested-by: Ojaswin Mujoo &lt;ojaswin@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20221223203638.41293-8-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fsverity: support verification with tree block size &lt; PAGE_SIZE</title>
<updated>2023-01-10T03:06:03+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-12-23T20:36:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5306892a50bf4cd4cc945bad286c7c950078d65e'/>
<id>urn:sha1:5306892a50bf4cd4cc945bad286c7c950078d65e</id>
<content type='text'>
Add support for verifying data from verity files whose Merkle tree block
size is less than the page size.  The main use case for this is to allow
a single Merkle tree block size to be used across all systems, so that
only one set of fsverity file digests and signatures is needed.

To do this, eliminate various assumptions that the Merkle tree block
size and the page size are the same:

- Make fsverity_verify_page() a wrapper around a new function
  fsverity_verify_blocks() which verifies one or more blocks in a page.

- When a Merkle tree block is needed, get the corresponding page and
  only verify and use the needed portion.  (The Merkle tree continues to
  be read and cached in page-sized chunks; that doesn't need to change.)

- When the Merkle tree block size and page size differ, use a bitmap
  fsverity_info::hash_block_verified to keep track of which Merkle tree
  blocks have been verified, as PageChecked cannot be used directly.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Andrey Albershteyn &lt;aalbersh@redhat.com&gt;
Tested-by: Ojaswin Mujoo &lt;ojaswin@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20221223203638.41293-7-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fsverity: pass pos and size to -&gt;write_merkle_tree_block</title>
<updated>2023-01-01T23:46:48+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-12-14T22:43:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=72ea15f0ddd29b9facdab836a2f5d3e28df9b202'/>
<id>urn:sha1:72ea15f0ddd29b9facdab836a2f5d3e28df9b202</id>
<content type='text'>
fsverity_operations::write_merkle_tree_block is passed the index of the
block to write and the log base 2 of the block size.  However, all
implementations of it use these parameters only to calculate the
position and the size of the block, in bytes.

Therefore, make -&gt;write_merkle_tree_block take 'pos' and 'size'
parameters instead of 'index' and 'log_blocksize'.

Suggested-by: Dave Chinner &lt;david@fromorbit.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Link: https://lore.kernel.org/r/20221214224304.145712-5-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fsverity: optimize fsverity_cleanup_inode() on non-verity files</title>
<updated>2023-01-01T23:46:48+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-12-14T22:43:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9642946c6c851ba954689f184b3370e3594b6b1a'/>
<id>urn:sha1:9642946c6c851ba954689f184b3370e3594b6b1a</id>
<content type='text'>
Make fsverity_cleanup_inode() an inline function that checks for
non-NULL -&gt;i_verity_info, then (if needed) calls
__fsverity_cleanup_inode() to do the real work.  This reduces the
overhead on non-verity files.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Link: https://lore.kernel.org/r/20221214224304.145712-4-ebiggers@kernel.org
</content>
</entry>
</feed>
