Carlos O'Donell
You know what sucks? Determining the owner of anonymous private or shared mappings? I feel like CONFIG_ANON_VMA_NAME could be really useful, but it's behind both a kernel config and a glibc tunable GLIBC_TUNABLES=glibc.mem.decorate_maps=1 ... we could make this better?
Jul 2, 2024 at 8:22pmWeb
Show threadKees Cook (old account)Jul 2, 2024

@codonell step one: put a new feature that people are suspicious about behind a config option. step two: get all distros to enable it. step three: make it default enabled in the kernel.

Each step takes a year or more usually, but this is how I tend to enable new kernel security features. :P

Show threadMichael Hudson-DoyleJul 2, 2024
@kees @codonell I'm here to help with step 2 :)
Show threadAdhemerval ZanellaJul 2, 2024
@codonell male the tunable a default maybe?
Show threadCarlos O'DonellJul 2, 2024
@zatrazz We can't yet because of the VMA merging consequences?
Show threadAdhemerval ZanellaJul 3, 2024
@codonell It is my understanding that setting a PR_SET_VMA_ANON_NAME to anonymous area might prevent that area from being merged with adjacent virtual memory areas. I am not sure if this would really matter for glibc current uses.
Show threadljsJul 3, 2024
@codonell I'm confused as to why the anon vma name would be useful for determining the VMA's owner? And under what circumstances are you unaware of the mm that owns it (i.e. vma->vm_mm)?

Even from proc's perspective you're pulling it from /proc/$pid/maps at which point you're aware of who it belongs to?

I may be missing something here!
Show threadCarlos O'DonellJul 3, 2024
@ljs The ownership model that matters to me is finding the code that called mmap() and determining the reason. For example: glibc allocated arena heaps, which we now decorate (https://inbox.sourceware.org/libc-alpha/[email protected]/T/) When assembling an application with hundreds of shared objects it isn't obvious over time who owns which anonymous mappings.
[PATCH v2 0/7] Add a tunable to decorate anonymous memory maps

Show threadCarlos O'DonellJul 3, 2024
@ljs The alternative solution to decoration is instrumentation. You run something, like systemtap, bpftrace, etc. to trace ALL mmap syscalls and record the stack callchain to identify the caller and possible cause. This is quite noisy because it contains transiently created mappings that may not really matter to total RSS usage. The even better alternative is extending massif or heaptrack to do this kind of instrumentation.
Show threadljsJul 3, 2024
@codonell right ok that makes sense. So 'owner' in the sense of the specific allocation (and some hint as to where this might have been done).

One issue is vma fragmentation because if you have adjacent VMAs that could merge but anon names don't match you (naturally) can't merge.

Really more of an issue if you are facing vma fragmentation issues (or hitting map limits)