<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/verity/enable.c, branch linux-6.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-07-19T14:35:08Z</updated>
<entry>
<title>fsverity: use shash API instead of ahash API</title>
<updated>2023-07-19T14:35:08Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2023-05-16T05:12:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=636d815cc35aa7967525d3b2a95ad02775847fd7'/>
<id>urn:sha1:636d815cc35aa7967525d3b2a95ad02775847fd7</id>
<content type='text'>
[ Upstream commit 8fcd94add6c5c93ed3b9314456e8420914401530 ]

The "ahash" API, like the other scatterlist-based crypto APIs such as
"skcipher", comes with some well-known limitations.  First, it can't
easily be used with vmalloc addresses.  Second, the request struct can't
be allocated on the stack.  This adds complexity and a possible failure
point that needs to be worked around, e.g. using a mempool.

The only benefit of ahash over "shash" is that ahash is needed to access
traditional memory-to-memory crypto accelerators, i.e. drivers/crypto/.
However, this style of crypto acceleration has largely fallen out of
favor and been superseded by CPU-based acceleration or inline crypto
engines.  Also, ahash needs to be used asynchronously to take full
advantage of such hardware, but fs/verity/ has never done this.

On all systems that aren't actually using one of these ahash-only crypto
accelerators, ahash just adds unnecessary overhead as it sits between
the user and the underlying shash algorithms.

Also, XFS is planned to cache fsverity Merkle tree blocks in the
existing XFS buffer cache.  As a result, it will be possible for a
single Merkle tree block to be split across discontiguous pages
(https://lore.kernel.org/r/20230405233753.GU3223426@dread.disaster.area).
This data will need to be hashed.  It is easiest to work with a vmapped
address in this case.  However, ahash is incompatible with this.

Therefore, let's convert fs/verity/ from ahash to shash.  This
simplifies the code, and it should also slightly improve performance for
everyone who wasn't actually using one of these ahash-only crypto
accelerators, i.e. almost everyone (or maybe even everyone)!

Link: https://lore.kernel.org/r/20230516052306.99600-1-ebiggers@kernel.org
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Stable-dep-of: d1f0c5ea04cd ("fsverity: don't use bio_first_page_all() in fsverity_verify_bio()")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds</title>
<updated>2023-04-12T02:23:23Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2023-04-06T21:31:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=04839139213cf60d4c5fc792214a08830e294ff8'/>
<id>urn:sha1:04839139213cf60d4c5fc792214a08830e294ff8</id>
<content type='text'>
Commit 56124d6c87fd ("fsverity: support enabling with tree block size &lt;
PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read
the file's data, instead of direct pagecache accesses.

An unintended consequence of this is that the
'WARN_ON_ONCE(!(file-&gt;f_mode &amp; FMODE_READ))' in __kernel_read() became
reachable by fuzz tests.  This happens if FS_IOC_ENABLE_VERITY is called
on a fd opened with access mode 3, which means "ioctl access only".

Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds.  But
ioctl-only fds are a weird Linux extension that is rarely used and that
few people even know about.  (The documentation for FS_IOC_ENABLE_VERITY
even specifically says it requires O_RDONLY.)  It's probably not
worthwhile to make the ioctl internally open a new fd just to handle
this case.  Thus, just reject the ioctl on such fds for now.

Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size &lt; PAGE_SIZE")
Reported-by: syzbot+51177e4144d764827c45@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=2281afcbbfa8fdb92f9887479cc0e4180f1c6b28
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230406215106.235829-1-ebiggers@kernel.org
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&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: explicitly check for buffer overflow in build_merkle_tree()</title>
<updated>2023-04-12T02:23:23Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2023-03-28T04:15:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=39049b69ec9fc125fa1f314165dcc86f72cb72ec'/>
<id>urn:sha1:39049b69ec9fc125fa1f314165dcc86f72cb72ec</id>
<content type='text'>
The new Merkle tree construction algorithm is a bit fragile in that it
may overflow the 'root_hash' array if the tree actually generated does
not match the calculated tree parameters.

This should never happen unless there is a filesystem bug that allows
the file size to change despite deny_write_access(), or a bug in the
Merkle tree logic itself.  Regardless, it's fairly easy to check for
buffer overflow here, so let's do so.

This is a robustness improvement only; this case is not currently known
to be reachable.  I've added a Fixes tag anyway, since I recommend that
this be included in kernels that have the mentioned commit.

Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size &lt; PAGE_SIZE")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230328041505.110162-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:15Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2023-03-28T04:03:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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: don't drop pagecache at end of FS_IOC_ENABLE_VERITY</title>
<updated>2023-03-16T05:50:41Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2023-03-14T23:31:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a075bacde257f755bea0e53400c9f1cdd1b8e8e6'/>
<id>urn:sha1:a075bacde257f755bea0e53400c9f1cdd1b8e8e6</id>
<content type='text'>
The full pagecache drop at the end of FS_IOC_ENABLE_VERITY is causing
performance problems and is hindering adoption of fsverity.  It was
intended to solve a race condition where unverified pages might be left
in the pagecache.  But actually it doesn't solve it fully.

Since the incomplete solution for this race condition has too much
performance impact for it to be worth it, let's remove it for now.

Fixes: 3fda4c617e84 ("fs-verity: implement FS_IOC_ENABLE_VERITY ioctl")
Cc: stable@vger.kernel.org
Reviewed-by: Victor Hsieh &lt;victorhsieh@google.com&gt;
Link: https://lore.kernel.org/r/20230314235332.50270-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
</content>
</entry>
<entry>
<title>fsverity: support enabling with tree block size &lt; PAGE_SIZE</title>
<updated>2023-01-10T03:06:06Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2022-12-23T20:36:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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: replace fsverity_hash_page() with fsverity_hash_block()</title>
<updated>2023-01-10T03:06:01Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2022-12-23T20:36:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f45555bf23cfc6bf0f0239de321221b1b81817ab'/>
<id>urn:sha1:f45555bf23cfc6bf0f0239de321221b1b81817ab</id>
<content type='text'>
In preparation for allowing the Merkle tree block size to differ from
PAGE_SIZE, replace fsverity_hash_page() with fsverity_hash_block().  The
new function is similar to the old one, but it operates on the block at
the given offset in the page instead of on the full page.

(For now, all callers still pass a full page.)

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-6-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fsverity: remove debug messages and CONFIG_FS_VERITY_DEBUG</title>
<updated>2023-01-01T23:46:48Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2022-12-15T06:04:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=86f66569baca98478b7ff2f49c8ee54cf3b108cd'/>
<id>urn:sha1:86f66569baca98478b7ff2f49c8ee54cf3b108cd</id>
<content type='text'>
I've gotten very little use out of these debug messages, and I'm not
aware of anyone else having used them.

Indeed, sprinkling pr_debug around is not really a best practice these
days, especially for filesystem code.  Tracepoints are used instead.

Let's just remove these and start from a clean slate.

This change does not affect info, warning, and error messages.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Link: https://lore.kernel.org/r/20221215060420.60692-1-ebiggers@kernel.org
</content>
</entry>
<entry>
<title>fsverity: pass pos and size to -&gt;write_merkle_tree_block</title>
<updated>2023-01-01T23:46:48Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2022-12-14T22:43:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.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>Merge tag 'folio-5.19' of git://git.infradead.org/users/willy/pagecache</title>
<updated>2022-05-25T02:55:07Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2022-05-25T02:55:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fdaf9a5840acaab18694a19e0eb0aa51162eeeed'/>
<id>urn:sha1:fdaf9a5840acaab18694a19e0eb0aa51162eeeed</id>
<content type='text'>
Pull page cache updates from Matthew Wilcox:

 - Appoint myself page cache maintainer

 - Fix how scsicam uses the page cache

 - Use the memalloc_nofs_save() API to replace AOP_FLAG_NOFS

 - Remove the AOP flags entirely

 - Remove pagecache_write_begin() and pagecache_write_end()

 - Documentation updates

 - Convert several address_space operations to use folios:
     - is_dirty_writeback
     - readpage becomes read_folio
     - releasepage becomes release_folio
     - freepage becomes free_folio

 - Change filler_t to require a struct file pointer be the first
   argument like -&gt;read_folio

* tag 'folio-5.19' of git://git.infradead.org/users/willy/pagecache: (107 commits)
  nilfs2: Fix some kernel-doc comments
  Appoint myself page cache maintainer
  fs: Remove aops-&gt;freepage
  secretmem: Convert to free_folio
  nfs: Convert to free_folio
  orangefs: Convert to free_folio
  fs: Add free_folio address space operation
  fs: Convert drop_buffers() to use a folio
  fs: Change try_to_free_buffers() to take a folio
  jbd2: Convert release_buffer_page() to use a folio
  jbd2: Convert jbd2_journal_try_to_free_buffers to take a folio
  reiserfs: Convert release_buffer_page() to use a folio
  fs: Remove last vestiges of releasepage
  ubifs: Convert to release_folio
  reiserfs: Convert to release_folio
  orangefs: Convert to release_folio
  ocfs2: Convert to release_folio
  nilfs2: Remove comment about releasepage
  nfs: Convert to release_folio
  jfs: Convert to release_folio
  ...
</content>
</entry>
</feed>
