fsverity: add dependency on 64K or smaller pages
Eric Biggers
maintainerPATCH 1/1 fsverity: add dependency on 64K or smaller pages
Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller.
64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used.
For now, just disable support for FS_VERITY in these odd configurations to ensure it isn't used in cases where it would have incorrect behavior.
--- fs/verity/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
fs/verity/Kconfig +3 -0
@@ -1,9 +1,12 @@ # SPDX-License-Identifier: GPL-2.0 config FS_VERITY bool "FS Verity (read-only file-based authenticity protection)" + # Filesystems cache the Merkle tree at a 64K aligned offset in the + # pagecache. That approach assumes the page size is at most 64K. + depends on PAGE_SHIFT <= 16 select CRYPTO_HASH_INFO select CRYPTO_LIB_SHA256 select CRYPTO_LIB_SHA512 help This option enables fs-verity. fs-verity is the dm-verity
base-commit: 8934827db5403eae57d4537114a9ff88b0a8460f
Signature · 1 line
2.53.0
Quoted 25 lines · Eric Biggers
Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller.
64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used.
For now, just disable support for
FS_VERITYin these odd configurations to ensure it isn't used in cases where it would have incorrect behavior.Fixes 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing")Reported-by Christoph Hellwig <[email protected]>Signed-off-by Eric Biggers <[email protected]>--- fs/verity/Kconfig | 3 +++ 1 file changed, 3 insertions(+)fs/verity/Kconfig +0
-0
fs/verity/Kconfig line 7
Quoted 7 lines
fs/verity/Kconfig +3
-0@@ -1,9 +1,12 @@ # SPDX-License-Identifier: GPL-2.0 config FS_VERITY bool "FS Verity (read-only file-based authenticity protection)" + # Filesystems cache the Merkle tree at a 64K aligned offset in the + # pagecache. That approach assumes the page size is at most 64K. + depends on PAGE_SHIFT <= 16
Makes sense to me, we have "depends on PAGE_SIZE_LESS_THAN_256KB" since somebody tried to use btrfs on the 256K system.
Quoted 13 lines · David Sterba
Quoted 12 lines · Eric Biggers
Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller.
64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used.
For now, just disable support for
FS_VERITYin these odd configurations to ensure it isn't used in cases where it would have incorrect behavior.
Quoted 7 lines
Quoted 4 lines
Fixes 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing")Reported-by Christoph Hellwig <[email protected]>Signed-off-by Eric Biggers <[email protected]>Makes sense to me, we have "depends on
PAGE_SIZE_LESS_THAN_256KB" since somebody tried to use btrfs on the 256K system.
I wonder if we should just drop the configuration entirely. There are very few users on either PowerPC44x (officially orphaned, but I know users) and Hexagon (officially supported, but no hardware available outside of Qualcomm). My impression is that this was implemented purely because the hardware can do it, not because anyone actually wants to use 256K pages.
I see that commit "e12401222f74 powerpc/44x: Support for 256KB PAGE_SIZE" mentions how one has to patch the linker to support larger than 64K pages, and I see that both powerpc and hexagon linkers still hardcode the section alignment to 64K pages, for obvious reasons.
Arnd
Quoted 11 lines · Eric Biggers
Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller.
64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used.
For now, just disable support for
FS_VERITYin these odd configurations to ensure it isn't used in cases where it would have incorrect behavior.
Do we want to throw in the towel here for the forseable future and if we ever need to support fsverity on > 64k page size just do a on-disk version rev?
Because if so we could just simply the pending xfs fsverity support to drop all the offset adjustment and simplify it a lot..
Theodore Tso
maintainerQuoted 6 lines · Christoph Hellwig
Do we want to throw in the towel here for the forseable future and if we ever need to support fsverity on > 64k page size just do a on-disk version rev?
Because if so we could just simply the pending xfs fsverity support to drop all the offset adjustment and simplify it a lot..
I wholeheartedly agree. Especially given the benefit of large folios, increasing the base page size beyond 64k has enough downsides without compelling upsides that can't be achieved via other means, I'm highly skeptical that page sizes > 64k is going to be appealing for most system designers. So trying to design in support for this possibility in fsverrity is not worth it.
- Ted
Quoted 9 lines · Eric Biggers
Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller.
64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used.
Quoted 7 lines
For now, just disable support for
FS_VERITYin these odd configurations to ensure it isn't used in cases where it would have incorrect behavior.Fixes 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing")Reported-by Christoph Hellwig <[email protected]>Signed-off-by Eric Biggers <[email protected]>
Quoted 12 lines · Eric Biggers
Currently, all filesystems that support fsverity (ext4, f2fs, and btrfs) cache the Merkle tree in the pagecache at a 64K aligned offset after the end of the file data. This offset needs to be a multiple of the page size, which is guaranteed only when the page size is 64K or smaller.
64K was chosen to be the "largest reasonable page size". But it isn't the largest *possible* page size: the hexagon and powerpc ports of Linux support 256K pages, though that configuration is rarely used.
For now, just disable support for
FS_VERITYin these odd configurations to ensure it isn't used in cases where it would have incorrect behavior.
Quoted 7 lines
Fixes 671e67b47e9f ("fs-verity: add Kconfig and the helper functions for hashing")Reported-by Christoph Hellwig <[email protected]>Signed-off-by Eric Biggers <[email protected]>--- fs/verity/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
Applied to https://git.kernel.org/pub/scm/fs/fsverity/linux.git/log/?h=for-current
- Eric