On Sun, Oct 20, 2024 at 07:37:54PM +0200, Florian Weimer wrote: > * Lorenzo Stoakes: > > > Early testing of the prototype version of this code suggests a 5 times > > speed up in memory mapping invocations (in conjunction with use of > > process_madvise()) and a 13% reduction in VMAs on an entirely idle android > > system and unoptimised code. > > > > We expect with optimisation and a loaded system with a larger number of > > guard pages this could significantly increase, but in any case these > > numbers are encouraging. > > > > This way, rather than having separate VMAs specifying which parts of a > > range are guard pages, instead we have a VMA spanning the entire range of > > memory a user is permitted to access and including ranges which are to be > > 'guarded'. > > > > After mapping this, a user can specify which parts of the range should > > result in a fatal signal when accessed. > > > > By restricting the ability to specify guard pages to memory mapped by > > existing VMAs, we can rely on the mappings being torn down when the > > mappings are ultimately unmapped and everything works simply as if the > > memory were not faulted in, from the point of view of the containing VMAs. > > We have a glibc (so not Android) dynamic linker bug that asks us to > remove PROT_NONE mappings in mapped shared objects: > > Extra struct vm_area_struct with ---p created when PAGE_SIZE < max-page-size > <https://sourceware.org/bugzilla/show_bug.cgi?id=31076> > > It's slightly different from a guard page because our main goal is to > avoid other mappings to end up in those gaps, which has been shown to > cause odd application behavior in cases where it happens. If I > understand the series correctly, the kernel would not automatically > attribute those PROT_NONE gaps to the previous or subsequent mapping. > We would have to extend one of the surrounding mapps and apply > MADV_POISON to that over-mapped part. That doesn't seem too onerous. > > Could the ELF loader in the kernel do the same thing for the main > executable and the program loader? Currently this implementation is only available for private anonymous memory. We may look at extending it to shmem and file-backed memory in the future but there are a whole host of things to overcome to make that work so it's one step at a time! :)
