All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org,
	Andrey Albershteyn <aalbersh@redhat.com>
Subject: Re: [PATCH v2 10/11] fs/buffer.c: support fsverity in block_read_full_folio()
Date: Mon, 9 Jan 2023 19:05:07 -0800	[thread overview]
Message-ID: <Y7zV41MQWSUGo4fw@sol.localdomain> (raw)
In-Reply-To: <20230109183759.c1e469f5f2181e9988f10131@linux-foundation.org>

On Mon, Jan 09, 2023 at 06:37:59PM -0800, Andrew Morton wrote:
> On Fri, 23 Dec 2022 12:36:37 -0800 Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > After each filesystem block (as represented by a buffer_head) has been
> > read from disk by block_read_full_folio(), verify it if needed.  The
> > verification is done on the fsverity_read_workqueue.  Also allow reads
> > of verity metadata past i_size, as required by ext4.
> 
> Sigh.  Do we reeeeealy need to mess with buffer.c in this fashion?  Did
> any other subsystems feel a need to do this?

ext4 is currently the only filesystem that uses block_read_full_folio() and that
supports fsverity.  However, since fsverity has a common infrastructure across
filesystems, in fs/verity/, it makes sense to support it in the other filesystem
infrastructure so that things aren't mutually exclusive for no reason.

Note that this applies to fscrypt too, which block_read_full_folio() (previously
block_read_full_page()) already supports since v5.5.

If you'd prefer that block_read_full_folio() be copied into ext4, then modified
to support fscrypt and fsverity, and then the fscrypt support removed from the
original copy, we could do that.  That seems more like a workaround to avoid
modifying certain files than an actually better solution, but it could be done.

> 
> > This is needed to support fsverity on ext4 filesystems where the
> > filesystem block size is less than the page size.
> 
> Does any real person actually do this?

Yes, on systems with the page size larger than 4K, the ext4 filesystem block
size is often smaller than the page size.  ext4 encryption (fscrypt) originally
had the same limitation, and Chandan Rajendra from IBM did significant work to
solve it a few years ago, with the changes landing in v5.5.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Albershteyn <aalbersh@redhat.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-xfs@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-btrfs@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v2 10/11] fs/buffer.c: support fsverity in block_read_full_folio()
Date: Mon, 9 Jan 2023 19:05:07 -0800	[thread overview]
Message-ID: <Y7zV41MQWSUGo4fw@sol.localdomain> (raw)
In-Reply-To: <20230109183759.c1e469f5f2181e9988f10131@linux-foundation.org>

On Mon, Jan 09, 2023 at 06:37:59PM -0800, Andrew Morton wrote:
> On Fri, 23 Dec 2022 12:36:37 -0800 Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > After each filesystem block (as represented by a buffer_head) has been
> > read from disk by block_read_full_folio(), verify it if needed.  The
> > verification is done on the fsverity_read_workqueue.  Also allow reads
> > of verity metadata past i_size, as required by ext4.
> 
> Sigh.  Do we reeeeealy need to mess with buffer.c in this fashion?  Did
> any other subsystems feel a need to do this?

ext4 is currently the only filesystem that uses block_read_full_folio() and that
supports fsverity.  However, since fsverity has a common infrastructure across
filesystems, in fs/verity/, it makes sense to support it in the other filesystem
infrastructure so that things aren't mutually exclusive for no reason.

Note that this applies to fscrypt too, which block_read_full_folio() (previously
block_read_full_page()) already supports since v5.5.

If you'd prefer that block_read_full_folio() be copied into ext4, then modified
to support fscrypt and fsverity, and then the fscrypt support removed from the
original copy, we could do that.  That seems more like a workaround to avoid
modifying certain files than an actually better solution, but it could be done.

> 
> > This is needed to support fsverity on ext4 filesystems where the
> > filesystem block size is less than the page size.
> 
> Does any real person actually do this?

Yes, on systems with the page size larger than 4K, the ext4 filesystem block
size is often smaller than the page size.  ext4 encryption (fscrypt) originally
had the same limitation, and Chandan Rajendra from IBM did significant work to
solve it a few years ago, with the changes landing in v5.5.

- Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2023-01-10  3:05 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-23 20:36 [PATCH v2 00/11] fsverity: support for non-4K pages Eric Biggers
2022-12-23 20:36 ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 01/11] fsverity: use unsigned long for level_start Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 02/11] fsverity: simplify Merkle tree readahead size calculation Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 03/11] fsverity: store log2(digest_size) precomputed Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 04/11] fsverity: use EFBIG for file too large to enable verity Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 05/11] fsverity: replace fsverity_hash_page() with fsverity_hash_block() Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 06/11] fsverity: support verification with tree block size < PAGE_SIZE Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 07/11] fsverity: support enabling " Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 08/11] ext4: simplify ext4_readpage_limit() Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 09/11] f2fs: simplify f2fs_readpage_limit() Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2022-12-23 20:36 ` [PATCH v2 10/11] fs/buffer.c: support fsverity in block_read_full_folio() Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2023-01-10  2:37   ` Andrew Morton
2023-01-10  2:37     ` [f2fs-dev] " Andrew Morton
2023-01-10  3:05     ` Eric Biggers [this message]
2023-01-10  3:05       ` Eric Biggers
2023-01-20 19:56       ` Eric Biggers
2023-01-20 19:56         ` [f2fs-dev] " Eric Biggers
2023-01-21  6:39         ` Christoph Hellwig
2023-01-21  6:39           ` [f2fs-dev] " Christoph Hellwig
2022-12-23 20:36 ` [PATCH v2 11/11] ext4: allow verity with fs block size < PAGE_SIZE Eric Biggers
2022-12-23 20:36   ` [f2fs-dev] " Eric Biggers
2023-01-04  6:38 ` [PATCH v2 00/11] fsverity: support for non-4K pages Ojaswin Mujoo
2023-01-04  6:38   ` [f2fs-dev] " Ojaswin Mujoo via Linux-f2fs-devel
2023-01-04  7:25   ` Eric Biggers
2023-01-04  7:25     ` [f2fs-dev] " Eric Biggers
2023-01-05 11:24     ` Ojaswin Mujoo
2023-01-05 11:24       ` [f2fs-dev] " Ojaswin Mujoo via Linux-f2fs-devel
2023-01-09 17:38 ` Eric Biggers
2023-01-09 17:38   ` [f2fs-dev] " Eric Biggers
2023-01-09 19:34   ` Andrey Albershteyn
2023-01-09 19:34     ` [f2fs-dev] " Andrey Albershteyn
2023-01-10  3:10     ` Eric Biggers
2023-01-10  3:10       ` [f2fs-dev] " Eric Biggers
2023-02-03 22:01 ` Eric Biggers
2023-02-03 22:01   ` [f2fs-dev] " Eric Biggers
2023-02-28  1:01 ` patchwork-bot+f2fs
2023-02-28  1:01   ` patchwork-bot+f2fs
2023-02-28  1:30   ` Eric Biggers
2023-02-28  1:30     ` [f2fs-dev] " Eric Biggers
2023-02-28  3:53     ` Jaegeuk Kim
2023-02-28  3:53       ` [f2fs-dev] " Jaegeuk Kim

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=Y7zV41MQWSUGo4fw@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=aalbersh@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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.