On Wed, Apr 15, 2026 at 04:10:00PM +0100, Matthew Wilcox wrote: > On Wed, Apr 15, 2026 at 04:04:50PM +0200, Miklos Szeredi wrote: > > On Wed, 15 Apr 2026 at 15:35, Gregory Price <[email protected]> wrote: > > > > > This was my first reaction when I realized the BPF program would be > > > controlling iomap return value in the fault path. Big ol' (!) popped > > > up over my head. > > > > I'm wondering which part of this triggers the big (!). > > > > BPF program being run in the fault path? > > > > Or that the return value from the BPF function is used as iomap? > > > > Or something else? > > If a BPF program controls what memory address a fault now allows access > to, who validates that this is a memory address within the purview of > the BPF program, and not, say, the address of the kernel page tables? > > (I have done no looking to determine if this is already considered)
>From an initial look at the existing bpf ops structures, I do not see any other struct with a similar (obvious) pattern - so it's not clear to me such a concern has been exposed elsewhere or directly addressed. There is a verifier step for the BPF program that in theory would validate the range matches the DAX ranges, but i think that only validates the types are right and only on load - I think the BPF program itself would be the address validater, which is a strong no. BPF folks please correct me if i'm off base here. My initial take is that it's a real concern a "bug" in a BPF program could let userland map arbitrary memory into userland page tables, and such an extension would not be a quick fix to the FAMFS problem. ~Gregory
