All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: linux-fscrypt@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
	Chris Mason <clm@fb.com>
Subject: Re: fsverity PAGE_SIZE constraints
Date: Mon, 1 Jun 2020 13:36:47 -0700	[thread overview]
Message-ID: <20200601203647.GB168749@gmail.com> (raw)
In-Reply-To: <69713333-8072-adf0-a6bb-8f73b3c390d0@trained-monkey.org>

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?

- Eric

  reply	other threads:[~2020-06-01 20:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01 20:13 fsverity PAGE_SIZE constraints Jes Sorensen
2020-06-01 20:36 ` Eric Biggers [this message]
2020-06-02 15:49   ` Chris Mason
2020-06-02 21:50     ` Eric Biggers
2020-06-03 13:57       ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200601203647.GB168749@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=clm@fb.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.