From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15EF53C73DA; Wed, 1 Apr 2026 22:27:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775082440; cv=none; b=ZLR6zJsLlXFxNaO1plFrMSyk1OXR8xfZlC8GR60iAreJV1EKuXsihSozeKTjGtP1lEdDpen2n3TSiH5FwjdNXf7261Svf7/ZLhEvX/M7zt9HkC4NE0C8nENu29WEspK5R2lc56ECX9Uw6FxEMQjpKO0jtKtm3S+FTa8n6p8Wb1w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775082440; c=relaxed/simple; bh=SYq0ujua23qXK/LmWqJZytMbuhwswv6VTuzwYXfuOO0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Evz3+cGsWAMbxjqNk5B6Z4gfIzQWRm3SMgR9YdkDo/hSpIRU8gBa8y2V/HkgEeauCHz+tAocT+at6SW+oIY/jWseOtFwVL6FSkKJiFFRX51mjBH4IlcFfjXmXQ2XqPAxC5CMrkYiP+UuNh1L7dkNSZen7Yv/cugc0JYJGBr/Xx8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B5PXSPnM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B5PXSPnM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E65FBC4CEF7; Wed, 1 Apr 2026 22:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775082439; bh=SYq0ujua23qXK/LmWqJZytMbuhwswv6VTuzwYXfuOO0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B5PXSPnM0g7dK54PuwCSAWqQJYwrb9QuFC3fNTXETKKaPEJa0LN6Qb71B1NKfCgkg zJ0YjonIndei8PlYKBNx5dFcfXhWpE+WBZbDACHmNuwim4lfvEmA3bvnNrqmY9fahl Rl9nb+RqNpAaOMAysgc+seVnfv95Xj1Oym+k9JlAwQFods4T+I06Kf50gAfdZgcbkj GbdbrTPPg+Vkh1rA4vuOIcDNMaHtAZoEjic2ruqY4tQldFn4TygR5eXvCGwAXISi6S kJWerpbb33PgwTewr82iGadRDTJWVbaKtQFxcemStEAmZQ7+vEhxTr9EO0FxOa60bl ti4gyubWkuz8Q== Date: Wed, 1 Apr 2026 15:27:17 -0700 From: Eric Biggers To: Andrey Albershteyn Cc: linux-xfs@vger.kernel.org, fsverity@lists.linux.dev, linux-fsdevel@vger.kernel.org, hch@lst.de, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH v6 03/22] fsverity: generate and store zero-block hash Message-ID: <20260401222717.GH2466@quark> References: <20260331212827.2631020-1-aalbersh@kernel.org> <20260331212827.2631020-4-aalbersh@kernel.org> Precedence: bulk X-Mailing-List: fsverity@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260331212827.2631020-4-aalbersh@kernel.org> On Tue, Mar 31, 2026 at 11:28:04PM +0200, Andrey Albershteyn wrote: > Compute the hash of one filesystem block's worth of zeros. A filesystem > implementation can decide to elide merkle tree blocks containing only > this hash and synthesize the contents at read time. > > Let's pretend that there's a file containing six data blocks and whose > merkle tree looks roughly like this: > > root > +--leaf0 > | +--data0 > | +--data1 > | `--data2 > `--leaf1 > +--data3 > +--data4 > `--data5 > > If data[0-2] are sparse holes, then leaf0 will contain a repeating > sequence of @zero_digest. Therefore, leaf0 need not be written to disk > because its contents can be synthesized. > > A subsequent xfs patch will use this to reduce the size of the merkle > tree when dealing with sparse gold master disk images and the like. > > Add a helper to pre-fill folio with hashes of empty blocks. This will be > used by iomap to synthesize blocks full of zero hashes on the fly. > > Signed-off-by: Darrick J. Wong > Signed-off-by: Andrey Albershteyn > --- > fs/verity/fsverity_private.h | 3 +++ > fs/verity/open.c | 3 +++ > fs/verity/pagecache.c | 22 ++++++++++++++++++++++ > include/linux/fsverity.h | 8 ++++++++ > 4 files changed, 36 insertions(+) Acked-by: Eric Biggers The example given in the commit message is a bit misleading, though. Usually there are actually 128 hashes per block, and a block of hashes covers 512 KiB. So this optimization applies only where there is a hole in the file's data of size (at least) 512 KiB, aligned to the same amount. It's also worth noting that this optimization is being done only for the first level. The levels above that are still being stored. So, this doesn't really enable e.g. exabyte sized sparse regions, as a block will still be stored for each 64 MiB (instead of every 512 KiB). I'm okay with this if you want to do this, but I just want to make sure its limitations are well-understood. > + /* the hash of a merkle block-sized buffer of zeroes */ > + u8 zero_digest[FS_VERITY_MAX_DIGEST_SIZE]; "the hash of an all-zeroes block" would be clearer. This is the hash from fsverity_hash_block() which includes the optional salt, not the hash from fsverity_hash_buffer() which does not include the salt. > +/** > + * fsverity_fill_zerohash() - fill folio with hashes of zero data block > + * @folio: folio to fill > + * @poff: offset in the folio to start > + * @plen: length of the range to fill with hashes Maybe go with (len, offset) for consistency with fsverity_verify_blocks(). (I assume the "p" prefix stands for "page", which is misleading since this works with a folio.) > +void fsverity_fill_zerohash(struct folio *folio, size_t poff, size_t plen, > + struct fsverity_info *vi) > +{ > + size_t offset = poff; > + > + WARN_ON_ONCE(!IS_ALIGNED(poff, vi->tree_params.digest_size)); > + WARN_ON_ONCE(!IS_ALIGNED(plen, vi->tree_params.digest_size)); > + > + for (; offset < (poff + plen); offset += vi->tree_params.digest_size) > + memcpy_to_folio(folio, offset, vi->tree_params.zero_digest, > + vi->tree_params.digest_size); This could be done more efficiently, especially on HIGHMEM. Probably fine for now though, especially since the intersection of anyone wanting XFS && fsverity && HIGHMEM is likely to be extremely small. - Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 941D910FCAE8 for ; Wed, 1 Apr 2026 22:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=i0MbL1F2vDAMDSFkZ3/3pFteFBy7cbqP882lOrL/nno=; b=N12ZvdITJwdsy4FBqU47Dn2QBH 6nh086aZKki9HAFTQEgR07dHVIXBG3sYsveN0ZXT8qukxlcDwkeP0M9gwhvjMYozFgjJ3gSVcQKWl 74n5t94vAFfg5W1n8ey2Y20sij9Cde2h+hxHmjiTumwyRYpoAXk5fpNDxxNAItLAqZtE=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1w842U-00021Y-RA; Wed, 01 Apr 2026 22:27:54 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1w8426-00021A-7M for linux-f2fs-devel@lists.sourceforge.net; Wed, 01 Apr 2026 22:27:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=k7HMgCpPVzoOCNhuAjZVYKMRt2o3N6/Rn9+h+RyHgJc=; b=SsL+MAbmWtLIipWn7hxZixSqzQ RWjgUE1ax76jmApLU0mO2XZuXL5hNOnXpVgNqs4WtCJbRLDn2IPdWmjfnWTLvM6TzNTw+r1Qe64Fn VS7icwSArorNHkB5SOV+51lwgmXBvKu/SYddcRAV+wcQx3ta+ofj6u9UIT+tVYE+AVDw=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=k7HMgCpPVzoOCNhuAjZVYKMRt2o3N6/Rn9+h+RyHgJc=; b=Q1JPpOIEYJvv7B9uwl7W6ym5Ry UbSRtKagLEoXHXxvBIWLG0EdJaN6HZICqWyd4YR6ietp7pUHHkZOKMtVlWEGcKqPvCEKqbl073oxi zX2L8gLvz0VfT6aQVLZwHtIKzbMg4Xabk2ueJadofixAilEmcEjsfYfAbC0g+wfXySJ0=; Received: from sea.source.kernel.org ([172.234.252.31]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1w8425-0003ev-Nx for linux-f2fs-devel@lists.sourceforge.net; Wed, 01 Apr 2026 22:27:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6391143B79; Wed, 1 Apr 2026 22:27:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E65FBC4CEF7; Wed, 1 Apr 2026 22:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775082439; bh=SYq0ujua23qXK/LmWqJZytMbuhwswv6VTuzwYXfuOO0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B5PXSPnM0g7dK54PuwCSAWqQJYwrb9QuFC3fNTXETKKaPEJa0LN6Qb71B1NKfCgkg zJ0YjonIndei8PlYKBNx5dFcfXhWpE+WBZbDACHmNuwim4lfvEmA3bvnNrqmY9fahl Rl9nb+RqNpAaOMAysgc+seVnfv95Xj1Oym+k9JlAwQFods4T+I06Kf50gAfdZgcbkj GbdbrTPPg+Vkh1rA4vuOIcDNMaHtAZoEjic2ruqY4tQldFn4TygR5eXvCGwAXISi6S kJWerpbb33PgwTewr82iGadRDTJWVbaKtQFxcemStEAmZQ7+vEhxTr9EO0FxOa60bl ti4gyubWkuz8Q== Date: Wed, 1 Apr 2026 15:27:17 -0700 To: Andrey Albershteyn Message-ID: <20260401222717.GH2466@quark> References: <20260331212827.2631020-1-aalbersh@kernel.org> <20260331212827.2631020-4-aalbersh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260331212827.2631020-4-aalbersh@kernel.org> X-Headers-End: 1w8425-0003ev-Nx Subject: Re: [f2fs-dev] [PATCH v6 03/22] fsverity: generate and store zero-block hash X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: fsverity@lists.linux.dev, djwong@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, hch@lst.de, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Tue, Mar 31, 2026 at 11:28:04PM +0200, Andrey Albershteyn wrote: > Compute the hash of one filesystem block's worth of zeros. A filesystem > implementation can decide to elide merkle tree blocks containing only > this hash and synthesize the contents at read time. > > Let's pretend that there's a file containing six data blocks and whose > merkle tree looks roughly like this: > > root > +--leaf0 > | +--data0 > | +--data1 > | `--data2 > `--leaf1 > +--data3 > +--data4 > `--data5 > > If data[0-2] are sparse holes, then leaf0 will contain a repeating > sequence of @zero_digest. Therefore, leaf0 need not be written to disk > because its contents can be synthesized. > > A subsequent xfs patch will use this to reduce the size of the merkle > tree when dealing with sparse gold master disk images and the like. > > Add a helper to pre-fill folio with hashes of empty blocks. This will be > used by iomap to synthesize blocks full of zero hashes on the fly. > > Signed-off-by: Darrick J. Wong > Signed-off-by: Andrey Albershteyn > --- > fs/verity/fsverity_private.h | 3 +++ > fs/verity/open.c | 3 +++ > fs/verity/pagecache.c | 22 ++++++++++++++++++++++ > include/linux/fsverity.h | 8 ++++++++ > 4 files changed, 36 insertions(+) Acked-by: Eric Biggers The example given in the commit message is a bit misleading, though. Usually there are actually 128 hashes per block, and a block of hashes covers 512 KiB. So this optimization applies only where there is a hole in the file's data of size (at least) 512 KiB, aligned to the same amount. It's also worth noting that this optimization is being done only for the first level. The levels above that are still being stored. So, this doesn't really enable e.g. exabyte sized sparse regions, as a block will still be stored for each 64 MiB (instead of every 512 KiB). I'm okay with this if you want to do this, but I just want to make sure its limitations are well-understood. > + /* the hash of a merkle block-sized buffer of zeroes */ > + u8 zero_digest[FS_VERITY_MAX_DIGEST_SIZE]; "the hash of an all-zeroes block" would be clearer. This is the hash from fsverity_hash_block() which includes the optional salt, not the hash from fsverity_hash_buffer() which does not include the salt. > +/** > + * fsverity_fill_zerohash() - fill folio with hashes of zero data block > + * @folio: folio to fill > + * @poff: offset in the folio to start > + * @plen: length of the range to fill with hashes Maybe go with (len, offset) for consistency with fsverity_verify_blocks(). (I assume the "p" prefix stands for "page", which is misleading since this works with a folio.) > +void fsverity_fill_zerohash(struct folio *folio, size_t poff, size_t plen, > + struct fsverity_info *vi) > +{ > + size_t offset = poff; > + > + WARN_ON_ONCE(!IS_ALIGNED(poff, vi->tree_params.digest_size)); > + WARN_ON_ONCE(!IS_ALIGNED(plen, vi->tree_params.digest_size)); > + > + for (; offset < (poff + plen); offset += vi->tree_params.digest_size) > + memcpy_to_folio(folio, offset, vi->tree_params.zero_digest, > + vi->tree_params.digest_size); This could be done more efficiently, especially on HIGHMEM. Probably fine for now though, especially since the intersection of anyone wanting XFS && fsverity && HIGHMEM is likely to be extremely small. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel