Re: [PATCH] bpf: add bpf_real_inode() kfunc

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/4/9 22:24, Christoph Hellwig wrote:
> On Thu, Apr 09, 2026 at 03:19:27PM +0200, Christian Brauner wrote:
>>> ways to do full file system verity [1] much more efficiently inside the
>>> file systems, and it would be good to not lock in a specific solution
>>
>> Note about that: we generally don't rely on any verity implementation
>> that makes the verity information itself part of the on-disk filesystem
>> format. The nice property of dm-verity is that the integrity is
>> completely separate from the filesystem format and it's basically simple
>> math that is trivially to prove correct.
> 
> Any file system integrated version storing the hashed in the extended
> LBA data (which Linux also confusingly calls intgrity data) would be
> even simpler and easier to verify.  But yes, we need to clearly
> document what we want.

Yes, you could keep hash / checksum in the extended OOB area, but
I guess you still don't know if the hash / checksum of the
particular data can be trusted (or is changed by attackers).

I think the key point of merkle tree approach is not only for
data integrity but also to distribute the trust between all
hashes by calculating the hash (of the hashes) of the hashes
so that you could get the only one root hash value regardless
of how to organize the container filesystem (meta)data so
that it's totally seperated from individual filesystem layouts
and can be proven seperately and even implemented easily by
hardware/firmware rather than inside the specific filesystem
implementation.

Thanks,
Gao Xiang