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

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

Hi Christoph,

On 2026/4/10 00:11, Christoph Hellwig wrote:
> On Thu, Apr 09, 2026 at 10:37:46PM +0800, Gao Xiang wrote:
>>> 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).
> 
> You'd still need to build a full merkle-tree out of them, but storing
> the leaf hashes in the extent LBAs means:

Yes, the leaf hashes can be stored in the extended
LBA area.

> 
>   - a lot less I/O amplification

But not quite sure recently how extended OOB data is
kept within the physical media (I remembered in the
early years each page of raw nand flashes has
several-byte OOB together with the user data): if
it's along with the corresponding LBA main area, I
guess it has to read extended data among multiple
LBAs (but the LBA main data may not relate to this
partcular I/O) in order to verify the hash of the
hashes.

>   - a sane way to actually have verification (including authenticated
>     encryption) in a writable file system

Yet if considering modification, it need to move up
the tree and recalculate/update all hashes until the
root hash, it's not a low-overhead task TBH, and need
to apply to every single on-disk change.

Thanks,
Gao Xiang