On 2/20/25 09:51, Lorenzo Stoakes wrote: > On Wed, Feb 19, 2025 at 12:56:31PM -0800, Kalesh Singh wrote: > > As I said to you earlier, the _best_ we could do in smaps would be to add a > flag like 'Grd' or something to indicate some part of the VMA is In smaps we could say how many kB is covered by guard ptes and it would be in line with the current output, and the fact it's already scanning page tables, so virtually no new overhead. But it wouldn't tell you the address ranges, of course. > guarded. But I won't do that unless somebody has an -actual use case- for > it. Right, we need to hear that first. Also I'm a bit confused about what's the issue with the existing Android apps and the proposals. Do the existing apps expect to see particular PROT_NONE regions, which would be gone (become part of the surrounding vma's) when using guards instead? Then clearly there's no way to use guards for them without breaking their assumptions. But assuming future versions of these apps for future android versions would have to adapt to guards instead of PROT_NONE, why do we have to promise them to represent the guards, if the point is just so they adapt to the new state of smaps in their dubious security checking code, and not break anymore? (but geez, if android apps are to use the android apis, which is java based (IIRC?) why were there ever allowed to read /proc in the first place? such a mistake, sigh) > David's /proc/$pid/pagemaps suggestion is excellent, avoids all the > pitfalls, exposes guard regions to anybody who really really wants to know > and doesn't interfere with anything else, so this is what we'll go with. > > Regards, Lorenzo
