linux-ext4 - Re: [PATCH v2 10/11] fs/buffer.c: support fsverity in block_read_full

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y7zV41MQWSUGo4fw@sol.localdomain>
Date:   Mon, 9 Jan 2023 19:05:07 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-fscrypt@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-btrfs@...r.kernel.org, linux-xfs@...r.kernel.org,
        Andrey Albershteyn <aalbersh@...hat.com>
Subject: Re: [PATCH v2 10/11] fs/buffer.c: support fsverity in
 block_read_full_folio()

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@...nel.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