All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Maxwell Bland <mbland@motorola.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Christoph Hellwig <hch@infradead.org>,
	Lorenzo Stoakes <lstoakes@gmail.com>
Subject: Re: [PATCH 1/5] mm: allow arch refinement/skip for vmap alloc
Date: Thu, 18 Apr 2024 10:55:16 +0200	[thread overview]
Message-ID: <ZiDf9AeFUG22CEU5@pc636> (raw)
In-Reply-To: <20240416122254.868007168-2-mbland@motorola.com>

On Tue, Apr 02, 2024 at 03:15:01PM -0500, Maxwell Bland wrote:
> Makes red black tree allocation more flexible on a per-architecture
> basis by introducing an optional hooks to refine the red-black tree
> structuring and exposing vmalloc functions for clipping vmap areas,
> finding vmap areas, and inserting vmap areas.
> 
> With this patch, the red-black vmap tree can be refined to account for
> architecture-specific memory management operations, most notably address
> space layout randomization, as these features conflict with generic
> management of a single vmalloc_start to vmalloc_end range as given by
> mm/vmalloc.c.
> 
> For example, x86 is forced to restrict aslr to 1024 possible locations,
> which is a very, very small number, and arm64 breaks standard code/data
> partitioning altogether, which prevents the enforcement of performant
> immmutability on kernel page tables.
> 
> Signed-off-by: Maxwell Bland <mbland@motorola.com>
> ---
>  include/linux/vmalloc.h | 24 ++++++++++++++++++++++++
>  mm/vmalloc.c            | 16 ++++++++++------
>  2 files changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 98ea90e90439..3c5ce7ee0bea 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -12,6 +12,7 @@
>  
>  #include <asm/vmalloc.h>
>  
> +struct kmem_cache;
>  struct vm_area_struct;		/* vma defining user mapping in mm_types.h */
>  struct notifier_block;		/* in notifier.h */
>  struct iov_iter;		/* in uio.h */
> @@ -125,6 +126,21 @@ static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot)
>  }
>  #endif
>  
> +#ifndef arch_skip_va
> +static inline bool arch_skip_va(struct vmap_area *va, unsigned long vstart)
> +{
> +	return false;
> +}
> +#endif
> +
> +#ifndef arch_refine_vmap_space
> +static inline void arch_refine_vmap_space(struct rb_root *root,
> +					  struct list_head *head,
> +					  struct kmem_cache *cachep)
> +{
> +}
> +#endif
> +
>  /*
>   *	Highlevel APIs for driver use
>   */
> @@ -214,6 +230,14 @@ extern struct vm_struct *__get_vm_area_caller(unsigned long size,
>  void free_vm_area(struct vm_struct *area);
>  extern struct vm_struct *remove_vm_area(const void *addr);
>  extern struct vm_struct *find_vm_area(const void *addr);
> +extern void insert_vmap_area_augment(struct vmap_area *va, struct rb_node *from,
> +				     struct rb_root *root,
> +				     struct list_head *head);
> +extern int va_clip(struct rb_root *root, struct list_head *head,
> +		   struct vmap_area *va, unsigned long nva_start_addr,
> +		   unsigned long size);
> +extern struct vmap_area *__find_vmap_area(unsigned long addr,
> +					  struct rb_root *root);
>
To me it looks like you want to make internal functions as public for
everyone which is not good, imho.

>  struct vmap_area *find_vmap_area(unsigned long addr);
>  
>  static inline bool is_vm_area_hugepages(const void *addr)
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 68fa001648cc..de4577a3708e 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -989,7 +989,7 @@ unsigned long vmalloc_nr_pages(void)
>  	return atomic_long_read(&nr_vmalloc_pages);
>  }
>  
> -static struct vmap_area *__find_vmap_area(unsigned long addr, struct rb_root *root)
> +struct vmap_area *__find_vmap_area(unsigned long addr, struct rb_root *root)
>  {
>  	struct rb_node *n = root->rb_node;
>  
> @@ -1322,7 +1322,7 @@ insert_vmap_area(struct vmap_area *va,
>  		link_va(va, root, parent, link, head);
>  }
>  
> -static void
> +void
>  insert_vmap_area_augment(struct vmap_area *va,
>  	struct rb_node *from, struct rb_root *root,
>  	struct list_head *head)
> @@ -1501,7 +1501,7 @@ find_vmap_lowest_match(struct rb_root *root, unsigned long size,
>  				vstart < va->va_start) {
>  			node = node->rb_left;
>  		} else {
> -			if (is_within_this_va(va, size, align, vstart))
> +			if (!arch_skip_va(va, vstart) && is_within_this_va(va, size, align, vstart))
>  				return va;
>  
>  			/*
> @@ -1522,7 +1522,8 @@ find_vmap_lowest_match(struct rb_root *root, unsigned long size,
>  			 */
>  			while ((node = rb_parent(node))) {
>  				va = rb_entry(node, struct vmap_area, rb_node);
> -				if (is_within_this_va(va, size, align, vstart))
> +				if (!arch_skip_va(va, vstart) &&
> +				    is_within_this_va(va, size, align, vstart))
>  					return va;
>  
>  				if (get_subtree_max_size(node->rb_right) >= length &&
> @@ -1554,7 +1555,7 @@ find_vmap_lowest_linear_match(struct list_head *head, unsigned long size,
>  	struct vmap_area *va;
>  
>  	list_for_each_entry(va, head, list) {
> -		if (!is_within_this_va(va, size, align, vstart))
> +		if (arch_skip_va(va, vstart) || !is_within_this_va(va, size, align, vstart))
>  			continue;
>  
arch_skip_va() injections into the search algorithm sounds like a hack
and might lead(if i do not miss something, need to check closer) to alloc
failures when we go toward a reserved VA but we are not allowed to allocate
from.

>  		return va;
> @@ -1617,7 +1618,7 @@ classify_va_fit_type(struct vmap_area *va,
>  	return type;
>  }
>  
> -static __always_inline int
> +__always_inline int
>  va_clip(struct rb_root *root, struct list_head *head,
>  		struct vmap_area *va, unsigned long nva_start_addr,
>  		unsigned long size)
> @@ -5129,4 +5130,7 @@ void __init vmalloc_init(void)
>  	vmap_node_shrinker->count_objects = vmap_node_shrink_count;
>  	vmap_node_shrinker->scan_objects = vmap_node_shrink_scan;
>  	shrinker_register(vmap_node_shrinker);
> +
> +	arch_refine_vmap_space(&free_vmap_area_root, &free_vmap_area_list,
> +			       vmap_area_cachep);
>  }
>
Why do not you allocate just using a specific range from MODULES_ASLR_START
till VMALLOC_END?

Thanks!

--
Uladzislau Rezki


  reply	other threads:[~2024-04-18  8:55 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 20:16 [PATCH 0/5] mm: code and data partitioning improvements Maxwell Bland
2024-04-16 19:18 ` [PATCH 0/5 RESEND] " Maxwell Bland
2024-04-16 19:18 ` Maxwell Bland
2024-04-16 19:18 ` Maxwell Bland
2024-04-16 19:18 ` Maxwell Bland
2024-04-15 20:16 ` [PATCH 0/5] " Maxwell Bland
2024-04-15 20:16 ` Maxwell Bland
2024-04-15 20:16 ` Maxwell Bland
2024-04-02 20:15 ` [PATCH 1/5] mm: allow arch refinement/skip for vmap alloc Maxwell Bland
2024-04-16 19:18   ` [PATCH 1/5 RESEND] " Maxwell Bland
2024-04-18  8:55   ` Uladzislau Rezki [this message]
2024-04-18 15:52     ` [PATCH 1/5] " Maxwell Bland
2024-04-03 21:08 ` [PATCH 2/5] arm64: mm: code and data partitioning for aslr Maxwell Bland
2024-04-16 19:18   ` [PATCH 2/5 RESEND] " Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-03 21:08   ` [PATCH 2/5] " Maxwell Bland
2024-04-17  5:14   ` kernel test robot
2024-04-17  5:14     ` kernel test robot
2024-04-05 18:37 ` [PATCH 3/5] mm: add vaddr param to pmd_populate_kernel Maxwell Bland
2024-04-16 19:18   ` [PATCH 3/5 RESEND] " Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-05 18:37   ` [PATCH 3/5] " Maxwell Bland
2024-04-05 18:37   ` Maxwell Bland
2024-04-05 18:37   ` Maxwell Bland
2024-04-17  8:23   ` kernel test robot
2024-04-12 15:00 ` [PATCH 4/5] arm64: dynamic enforcement of PXNTable Maxwell Bland
2024-04-16 19:18   ` [PATCH 4/5 RESEND] " Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-12 15:00   ` [PATCH 4/5] " Maxwell Bland
2024-04-17  6:37   ` [PATCH 4/5 RESEND] " kernel test robot
2024-04-17  6:37     ` kernel test robot
2024-04-15 19:51 ` [PATCH 5/5] ptdump: add state parameter for non-leaf callback Maxwell Bland
2024-04-16 19:18   ` [PATCH 5/5 RESEND] " Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-16 19:18   ` Maxwell Bland
2024-04-15 19:51   ` [PATCH 5/5] " Maxwell Bland
2024-04-15 19:51   ` Maxwell Bland
2024-04-15 19:51   ` Maxwell Bland
2024-04-16 20:11   ` Andrew Morton
2024-04-16 20:11     ` Andrew Morton
2024-04-16 20:11     ` Andrew Morton
2024-04-16 20:11     ` Andrew Morton
2024-04-16 21:01     ` Maxwell Bland
2024-04-16 21:01       ` Maxwell Bland
2024-04-16 21:01       ` Maxwell Bland
2024-04-16 21:01       ` Maxwell Bland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZiDf9AeFUG22CEU5@pc636 \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mbland@motorola.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.