Re: fsverity PAGE_SIZE constraints

"Chris Mason" <clm@xxxxxx> · Tue, 02 Jun 2020 11:49:36 -0400

On 1 Jun 2020, at 16:36, Eric Biggers wrote:

On Mon, Jun 01, 2020 at 04:13:45PM -0400, Jes Sorensen wrote:

Hi,

I am working on adding fsverity support to RPM and I am hitting a 

tricky

problem. I am see this with RPM, but it really isn't specific to RPM,
and will apply to any method for distribution signatures.

fsverity is currently hard-wiring the Merkle tree block size to

PAGE_SIZE. This is problematic for a number of reasons, in particular 

on

architectures that can be configured with different page sizes, such 

as

ARM, as well as the case where someone generates a shared 'common'
package to be used cross architectures (noarch package in RPM terms).

For a package manager to be able to create a generic package with
signatures, it basically has to build a signature for every supported
page size of the target architecture.

Chris Mason is working on adding fsverity support to btrfs, and I
understand he is supporting 4K as the default Merkle tree block size,
independent of the PAGE_SIZE.

Would it be feasible to make ext4 and other file systems support 4K 

for

non 4K page sized systems and make that a general recommendation 

going

forward?

It's possible, but it will be a little difficult.  We made a similar

simplification for ext4 encryption initially, and it took a long time 

to remove

it.  (ext4 encryption was first supported in Linux v4.1.  ext4 

encryption didn't

support block_size != PAGE_SIZE until Linux v5.5, following work by
Chandan Rajendra and myself.)

Fixing this would require a number of different changes:

- Updating fscrypt_verify_bio() and fsverity_verity_page() to iterate 

through

  all data blocks in each page, and to handle sub-page Merkle tree 

blocks

- Defining a mechanism other than PageChecked to mark Merkle tree 

blocks as

  verified.  E.g., allocating an in-memory bitmap as part of the 

struct

  fsverity_info.  This should also be optional, in the sense that we 

shouldn't

  use the memory for it when it's not needed.

- Supporting fs-verity in block_read_full_page() in fs/buffer.c.

There may be other changes needed too; those are just the obvious 

ones.

Is this something that you or Chris is interested in working on?

On the btrfs side, I’m storing the fsverity data in the btree, so 

I’m merkle block size agnostic.  Since our rollout is going to be x86, 

we’ll end up using the 4k size internally for the current code base.

My recommendation to simplify the merkle tree code would be to just put 

it in slab objects instead pages and leverage recent MM changes to make 

reclaim work well.  There’s probably still more to do on that front, 

but it’s a long standing todo item for Josef to shift the btrfs 

metadata out of the page cache, where we have exactly the same problems 

for exactly the same reasons.

-chris