On Mon, Jul 8, 2024 at 6:27 PM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > > > So what exactly did you have in mind when you were proposing that > > check? Did you mean to do a pass over all VMAs within the process to > > check if there is at least one executable VMA belonging to > > address_space? If yes, then that would certainly be way too expensive > > to be usable. > > I was thinking to only report the build ID when the VMA queried > is executable. If software wanted to look up a data symbol > and needs that buildid it would need to check a x vma too. I think that's way too restrictive and for no good reason, tbh. If there is some .rodata ELF section mapped as r/o VMA, I don't see any reason why user shouldn't be able to request build ID for it. > > Normally tools iterate over all the mappings anyways so this > shouldn't be a big burden for them. > This API aims to make this unnecessary. So that tools can request only relevant VMAs based on whatever captured data or code addresses it got from, say, profiling of perf events. And if there are some locks or other global data structures that fall into mapped portions of ELF data sections, the ability to get build ID for those is just as important as getting build ID for executable sections. > Did I miss something? > > I guess an alternative would be a new VMA flag, but iirc we're low on > bits there already. I think we should just keep things as is. I don't think there is any real added security in restricting this just to executable VMAs. > > -Andi
