Re: [PATCH] btrfs: add BTRFS_IOC_GET_CSUMS ioctl

[Boris Burkov <boris@bur.io>]

On Fri, Apr 03, 2026 at 08:16:26AM +1030, Qu Wenruo wrote:
> 
> 
> 在 2026/4/3 03:35, Mark Harmstone 写道:
> > On 25/03/2026 9.04 pm, Qu Wenruo wrote:
> [...]
> > > 
> > > That's done by progs through fiemap. There will be a flag ENCODED
> > > for compressed file extents.
> > 
> > No, this still won't work I'm afraid. The ioctl is answering the
> > question "what's the csum of the sector no. such-and-such in this
> > file?". That can't be answered for compressed extents, as the csums are
> > on the compressed data.
> 
> My point is, since you are not trying to fetching the csum of compressed
> extent in the first place, you don't need to bother that situation at all.
> 
> And even for compressed extents, it is still possible to fetch the csum,
> after all we're just search the csum tree for a given logical bytenr.
> 
> There will be some extra concerns like fiemap can not return the real
> compressed length, but again we ruled our compressed extents in the first
> place.
> 

I may be misinterpreting, but I feel like the question at hand is how
much hardening the ioctl requires to be correct, and how much work it
can delegate to userspace.

Suppose we make it require root, I think we could make the interface
much simpler and just use the logical offsets instead of a file based
interface, and we can leave it up to userspace entirely to figure out
which ranges they care about.

OTOH, if we agree we want the csums ioctl to be unprivileged, which
means that the interface must assume that the input could be bad, on
overlapping extents, not marked up properly, etc... In that case, I do
not quite know *exactly* what is redundant with fiemap, what is exactly
necessary for safety vs for caller convenience, etc.

Basically, I think the options are roughly:

- Mark's proposal: A smart, convenient GET_CSUMS that does everything
  turnkey and as helpfully as possible. Lots of redundance with fiemap.
  Safe to make unprivileged.
- Qu's review: Require the user to do the fiemap part themselves and
  don't make GET_CSUMS quite as turnkey. It is unclear to me whether it
  is possible to make such a version unprivileged safely *without*
  the fiemap redundancy.
- Boris's strawman: A dumb, inconvenient GET_CSUMS that expects a lot of
  userspace but doesn't check anything and definitely needs root. If we
  do go root-only, I feel like this might be the best interface?

And the questions are:
1. How badly do we want non-root? In practice, mkfs is root when writing
disks but not necessarily when writing image files, so it's a bit of a
toss up there. At meta we tend to end up sad when mkfs has root-only
functionality that we want.
2. What is the bare minimum processing needed to safely allow non-root
callers with arbitrarily wrong input? I don't see how we can assume they
will use fiemap correctly and not hit bookends, or set correct tags on
the input, for a few examples.

Thanks,
Boris

> > 
> > There might be a use case for "fetch the csums for a compressed extent",
> > but it'd be something different.
> > 
> > My concern about relying on ENCODED is that that would also be set when
> > we implement encryption. For an encrypted uncompressed extent the csum
> > *would* be meaningful.
> > 
> > > > The reason is that they may be "bookended", and you would leak
> > > > information about other files if you returned the whole of the
> > > > csums for the compressed extent. This is the reason why encoded
> > > > read needs root.
> > > 
> > > Nope, for the fiemap call, we will never reach any bookend extents.
> > 
> > I really don't think the FIEMAP call achieves anything here. The kernel
> > still has to do a lookup in the FS tree to determine what the logical
> > address of the extent is.
> 
> The point is to minimize the work in kernel.
> 
> We already have a ioctl to do the fs tree lookup, and it is definitely
> enough for non-compressed extents, and that's fiemap ioctl.
> 
> Thus I do not want to introduce new codes just to do a similar thing again.
> 
> > We can't allow (non-root) users to read the csums of arbitrary sectors.
> 
> And that's your choice on the csum ioctl, I have no preference, since fiemap
> doesn't require root privilege anyway, if you want root check I see no
> problem either since it's more secure.
> 
> Thanks,
> Qu