Re: [PATCH v2] mm/vmalloc: widen guard region to defeat ENTER-based stack pivot

[Dave Hansen <dave.hansen@intel.com>]

On 6/30/26 07:40, Pedro Falcato wrote:
>>> To even be considered, this series needs to be refactored properly.
>>> Making this VMAP_GUARD_PAGES a separate patch is the bare minimum.
>>>
>> Good suggestion, I will do it in v3:
>>
>>     1/3 - introduce VMAP_GUARD_PAGES
>>     2/3 - mark percpu vmap areas VM_NO_GUARD
> I would suggest you create a VMAP_STACK flag and condition these guard regions
> bsaed on that. Otherwise it's a bit arbitrary as to what callers get 0x11 guard
> pages, and which don't.
> 
> (you can find the concrete stack allocation functions in kernel/fork.c)

The real question here is whether VMAP_STACK is a good idea or whether
__get_vm_area_node() should grow functionality to manipulate guard gaps
and then just have the stack allocation code use it directly.

I, personally, despise code like this:

static inline size_t get_vm_area_size(const struct vm_struct *area)
{
        if (!(area->flags & VM_NO_GUARD))
                /* return actual size without guard page */
                return area->size - PAGE_SIZE;
        else
                return area->size;

}

I'd *much* rather it be something more like:

static inline size_t get_vm_area_size(const struct vm_struct *area)
{
	return area->size - area->gap;
}

for example.

Looking at every use of VM_NO_GUARD, I think the kernel just gets
simpler if it goes away. It's only referenced in 6 sites:

 1. __get_vm_area_node() - Munge gap argument into 'area'
 2. get_vm_area_size() can be replaced as I showed above
 3. kasan_mem_notifier() - just pass a gap=0 to __get_vm_area_node()
 4. kasan_alloc_module_shadow() - just pass a gap=0
 5. check_sparse_vm_area() - check area->gap instead
 6. Just remove VM_NO_GUARD checks. No flag means no munging the flag.