All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Zong Li <zong.li@sifive.com>
Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	alex@ghiti.fr, debug@rivosinc.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB
Date: Thu, 14 May 2026 09:56:05 +0100	[thread overview]
Message-ID: <20260514095605.2c7d8761@pumpkin> (raw)
In-Reply-To: <20260514075036.1432352-1-zong.li@sifive.com>

On Thu, 14 May 2026 00:50:35 -0700
Zong Li <zong.li@sifive.com> wrote:

> Follow the ARM64 GCS (Guarded Control Stack) implementation approach
> by reducing the shadow stack size allocation from min(RLIMIT_STACK, 4GB)
> to min(RLIMIT_STACK/2, 2GB). see commit '506496bcbb42 "arm64/gcs: Ensure
> that new threads have a GCS")'
> 
> Rationale:
> 
> 1. Shadow stacks only store return addresses (8 bytes per entry), not
>    local variables, function parameters, or saved registers. A 2GB
>    shadow stack is far more than sufficient for any practical
>    application, even with extremely deep recursion. Using half the size
>    maintains adequate while being more resource-efficient margin
> 
> 2. On memory-constrained systems (e.g., platforms with only 4GB of
>    physical memory, which is a common configuration), allocating 4GB
>    of virtual address space for shadow stack per process/thread can
>    lead to virtual memory allocation failures when the overcommit mode
>    is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER:
>    Error: "__vm_enough_memory: not enough memory for the allocation"
> 
> This reduces virtual address space consumption by 50% while maintaining
> more than adequate space for return address storage.
> 
> Additionally, add max(PAGE_SIZE, size) constraint, which covers the
> case where RLIMIT_STACK is smaller than PAGE_SIZE.
> 
> Signed-off-by: Zong Li <zong.li@sifive.com>
> ---
> 
> Changed in v2:
> - Add max() in case RLIMIT_STACK is smaller than PAGE_SIZE. Suggested by
>   Paul Walmsley and Sashiko
> 
> Changed in v1:
> - Use min() instead of min_t(). Suggested by David Laight
> 
>  arch/riscv/kernel/usercfi.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c
> index 6eaa0d94fdfe..0f75e8f5d0ec 100644
> --- a/arch/riscv/kernel/usercfi.c
> +++ b/arch/riscv/kernel/usercfi.c
> @@ -109,15 +109,17 @@ void set_indir_lp_lock(struct task_struct *task, bool lock)
>  	task->thread_info.user_cfi_state.ufcfi_locked = lock;
>  }
>  /*
> - * If size is 0, then to be compatible with regular stack we want it to be as big as
> - * regular stack. Else PAGE_ALIGN it and return back
> + * The shadow stack only stores the return address and not any variables
> + * 2G should be more than sufficient for most applications.
>   */
>  static unsigned long calc_shstk_size(unsigned long size)
>  {
>  	if (size)
>  		return PAGE_ALIGN(size);
>  
> -	return PAGE_ALIGN(min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G));
> +	size = PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 2, SZ_2G));

PAGE_ALIGN() already rounds up, so the only problem would be if rlimit(STACK)
were 0 or 1, I'm sure that would fail earlier (or not be allowed).

I also don't understand the rational for just /2 and the 2G upper limit.
You need 512 nested function calls to even use 4k.
That would have to be quite deep recursion.

-- David

> +
> +	return max(PAGE_SIZE, size);
>  }
>  
>  /*


WARNING: multiple messages have this Message-ID (diff)
From: David Laight <david.laight.linux@gmail.com>
To: Zong Li <zong.li@sifive.com>
Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	alex@ghiti.fr, debug@rivosinc.com,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB
Date: Thu, 14 May 2026 09:56:05 +0100	[thread overview]
Message-ID: <20260514095605.2c7d8761@pumpkin> (raw)
In-Reply-To: <20260514075036.1432352-1-zong.li@sifive.com>

On Thu, 14 May 2026 00:50:35 -0700
Zong Li <zong.li@sifive.com> wrote:

> Follow the ARM64 GCS (Guarded Control Stack) implementation approach
> by reducing the shadow stack size allocation from min(RLIMIT_STACK, 4GB)
> to min(RLIMIT_STACK/2, 2GB). see commit '506496bcbb42 "arm64/gcs: Ensure
> that new threads have a GCS")'
> 
> Rationale:
> 
> 1. Shadow stacks only store return addresses (8 bytes per entry), not
>    local variables, function parameters, or saved registers. A 2GB
>    shadow stack is far more than sufficient for any practical
>    application, even with extremely deep recursion. Using half the size
>    maintains adequate while being more resource-efficient margin
> 
> 2. On memory-constrained systems (e.g., platforms with only 4GB of
>    physical memory, which is a common configuration), allocating 4GB
>    of virtual address space for shadow stack per process/thread can
>    lead to virtual memory allocation failures when the overcommit mode
>    is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER:
>    Error: "__vm_enough_memory: not enough memory for the allocation"
> 
> This reduces virtual address space consumption by 50% while maintaining
> more than adequate space for return address storage.
> 
> Additionally, add max(PAGE_SIZE, size) constraint, which covers the
> case where RLIMIT_STACK is smaller than PAGE_SIZE.
> 
> Signed-off-by: Zong Li <zong.li@sifive.com>
> ---
> 
> Changed in v2:
> - Add max() in case RLIMIT_STACK is smaller than PAGE_SIZE. Suggested by
>   Paul Walmsley and Sashiko
> 
> Changed in v1:
> - Use min() instead of min_t(). Suggested by David Laight
> 
>  arch/riscv/kernel/usercfi.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c
> index 6eaa0d94fdfe..0f75e8f5d0ec 100644
> --- a/arch/riscv/kernel/usercfi.c
> +++ b/arch/riscv/kernel/usercfi.c
> @@ -109,15 +109,17 @@ void set_indir_lp_lock(struct task_struct *task, bool lock)
>  	task->thread_info.user_cfi_state.ufcfi_locked = lock;
>  }
>  /*
> - * If size is 0, then to be compatible with regular stack we want it to be as big as
> - * regular stack. Else PAGE_ALIGN it and return back
> + * The shadow stack only stores the return address and not any variables
> + * 2G should be more than sufficient for most applications.
>   */
>  static unsigned long calc_shstk_size(unsigned long size)
>  {
>  	if (size)
>  		return PAGE_ALIGN(size);
>  
> -	return PAGE_ALIGN(min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G));
> +	size = PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 2, SZ_2G));

PAGE_ALIGN() already rounds up, so the only problem would be if rlimit(STACK)
were 0 or 1, I'm sure that would fail earlier (or not be allowed).

I also don't understand the rational for just /2 and the 2G upper limit.
You need 512 nested function calls to even use 4k.
That would have to be quite deep recursion.

-- David

> +
> +	return max(PAGE_SIZE, size);
>  }
>  
>  /*


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-05-14  8:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  7:50 [PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB Zong Li
2026-05-14  7:50 ` Zong Li
2026-05-14  8:56 ` David Laight [this message]
2026-05-14  8:56   ` David Laight
2026-05-15  3:42   ` Zong Li
2026-05-15  3:42     ` Zong Li
2026-05-15  9:24     ` David Laight
2026-05-15  9:24       ` David Laight
2026-05-15 14:29       ` Zong Li
2026-05-15 14:29         ` Zong Li
2026-05-15 19:16         ` David Laight
2026-05-15 19:16           ` David Laight

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=20260514095605.2c7d8761@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=debug@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=zong.li@sifive.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.