[PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB

[PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB

[Zong Li]

Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at
2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's
analysis and recommendation.

Rationale:

David Laight pointed out that the focus should be on the ratio between
shadow stack size and the normal stack size, rather than just the
absolute upper limit. His analysis showed that while there are many
functions with small stack frames, the majority have stack deltas of
over 64 bytes due to saved registers and local variables.

Shadow stacks only store return addresses (8 bytes per entry on 64-bit
systems), whereas normal stack frames typically consume 64+ bytes. This
8:64 byte ratio means that programs using a lot of stack space are
dominated by large buffer allocations and local variables, not extreme
recursion depths with minimal local data.

For example, with the default RLIMIT_STACK of 8MB:
- RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls
- RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls

Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still
conservative and provides adequate depth for practical applications.
David noted that this could even be safely halved again.

This reduction also better accommodates memory-constrained platforms.
On systems with limited physical memory, allocating large shadow stacks
can cause virtual memory allocation failures when overcommit mode is set
to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER.

Suggested-by: David Laight <david.laight.linux@gmail.com>
Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/
Signed-off-by: Zong Li <zong.li@sifive.com>
---
 arch/riscv/kernel/usercfi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c
index cbfb4e495e9f..adf97426a906 100644
--- a/arch/riscv/kernel/usercfi.c
+++ b/arch/riscv/kernel/usercfi.c
@@ -110,7 +110,7 @@ void set_indir_lp_lock(struct task_struct *task, bool lock)
 }
 /*
  * The shadow stack only stores the return address and not any variables
- * this should be more than sufficient for most applications.
+ * 512M should be more than sufficient for most applications.
  * Else PAGE_ALIGN it and return back
  */
 static unsigned long calc_shstk_size(unsigned long size)
@@ -118,7 +118,7 @@ static unsigned long calc_shstk_size(unsigned long size)
 	if (size)
 		return PAGE_ALIGN(size);
 
-	return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 2, SZ_2G));
+	return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 8, SZ_512M));
 }
 
 /*
-- 
2.43.7

Re: [PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB

[Zong Li]

On Fri, May 22, 2026 at 5:36 PM Zong Li <zong.li@sifive.com> wrote:
>
> Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at
> 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's
> analysis and recommendation.
>
> Rationale:
>
> David Laight pointed out that the focus should be on the ratio between
> shadow stack size and the normal stack size, rather than just the
> absolute upper limit. His analysis showed that while there are many
> functions with small stack frames, the majority have stack deltas of
> over 64 bytes due to saved registers and local variables.
>
> Shadow stacks only store return addresses (8 bytes per entry on 64-bit
> systems), whereas normal stack frames typically consume 64+ bytes. This
> 8:64 byte ratio means that programs using a lot of stack space are
> dominated by large buffer allocations and local variables, not extreme
> recursion depths with minimal local data.
>
> For example, with the default RLIMIT_STACK of 8MB:
> - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls
> - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls
>
> Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still
> conservative and provides adequate depth for practical applications.
> David noted that this could even be safely halved again.
>
> This reduction also better accommodates memory-constrained platforms.
> On systems with limited physical memory, allocating large shadow stacks
> can cause virtual memory allocation failures when overcommit mode is set
> to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER.
>

Adding Mark, Szabolcs and Catalin to this thread.

I noticed your previous discussions about the shadow stack size in the
ARM64 GCS patch series. I see that the GCS size was eventually reduced
from 4G to 2G.

Because the RISC-V shadow stack stores very similar data to GCS, I
also reduced the RISC-V shadow stack size to 2G in my recent patch.
You can find the reasons for this change here:
https://lists.infradead.org/pipermail/linux-riscv/2026-May/091308.html

In the same thread, we discussed if we could make the size even
smaller. Thank David for his helpful analysis on this topic.

Since GCS has been merged for a few years now, we'd like to learn from
your experience. We want to make sure we are not missing any important
impacts or issues. Therefore, we would really appreciate it if you
could share your thoughts with us. This will give us the confidence to
move forward with the patch

Thanks


> Suggested-by: David Laight <david.laight.linux@gmail.com>
> Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/
> Signed-off-by: Zong Li <zong.li@sifive.com>
> ---
>  arch/riscv/kernel/usercfi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c
> index cbfb4e495e9f..adf97426a906 100644
> --- a/arch/riscv/kernel/usercfi.c
> +++ b/arch/riscv/kernel/usercfi.c
> @@ -110,7 +110,7 @@ void set_indir_lp_lock(struct task_struct *task, bool lock)
>  }
>  /*
>   * The shadow stack only stores the return address and not any variables
> - * this should be more than sufficient for most applications.
> + * 512M should be more than sufficient for most applications.
>   * Else PAGE_ALIGN it and return back
>   */
>  static unsigned long calc_shstk_size(unsigned long size)
> @@ -118,7 +118,7 @@ static unsigned long calc_shstk_size(unsigned long size)
>         if (size)
>                 return PAGE_ALIGN(size);
>
> -       return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 2, SZ_2G));
> +       return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 8, SZ_512M));
>  }
>
>  /*
> --
> 2.43.7
>

Re: [PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

On Thu, May 28, 2026 at 09:07:04AM +0800, Zong Li wrote:

> Because the RISC-V shadow stack stores very similar data to GCS, I
> also reduced the RISC-V shadow stack size to 2G in my recent patch.
> You can find the reasons for this change here:
> https://lists.infradead.org/pipermail/linux-riscv/2026-May/091308.html

> In the same thread, we discussed if we could make the size even
> smaller. Thank David for his helpful analysis on this topic.

> Since GCS has been merged for a few years now, we'd like to learn from
> your experience. We want to make sure we are not missing any important
> impacts or issues. Therefore, we would really appreciate it if you
> could share your thoughts with us. This will give us the confidence to
> move forward with the patch

Nobody has reported it causing them a problem, but there's not really
much practical use yet due to hardware availability so that might change
and I'm not sure how much inference you can draw there - there is much
more test use than production use at this stage.  I would be astonished
if anyone wanted the shadow stack to be bigger, the more likely problem
is excessive VA usage but we felt it was better to err on the side of
using too much memory.  The general feedback from userspace people was
that they weren't too concerned about issues.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB

[Zong Li]

> On Thu, May 28, 2026 at 9:07 AM Zong Li <zong.li@sifive.com> wrote:
> >
> > On Fri, May 22, 2026 at 5:36 PM Zong Li <zong.li@sifive.com> wrote:
> > >
> > > Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at
> > > 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's
> > > analysis and recommendation.
> > >
> > > Rationale:
> > >
> > > David Laight pointed out that the focus should be on the ratio between
> > > shadow stack size and the normal stack size, rather than just the
> > > absolute upper limit. His analysis showed that while there are many
> > > functions with small stack frames, the majority have stack deltas of
> > > over 64 bytes due to saved registers and local variables.
> > >
> > > Shadow stacks only store return addresses (8 bytes per entry on 64-bit
> > > systems), whereas normal stack frames typically consume 64+ bytes. This
> > > 8:64 byte ratio means that programs using a lot of stack space are
> > > dominated by large buffer allocations and local variables, not extreme
> > > recursion depths with minimal local data.
> > >
> > > For example, with the default RLIMIT_STACK of 8MB:
> > > - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls
> > > - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls
> > >
> > > Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still
> > > conservative and provides adequate depth for practical applications.
> > > David noted that this could even be safely halved again.
> > >
> > > This reduction also better accommodates memory-constrained platforms.
> > > On systems with limited physical memory, allocating large shadow stacks
> > > can cause virtual memory allocation failures when overcommit mode is set
> > > to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER.
> > >
> >
> > Adding Mark, Szabolcs and Catalin to this thread.
> >
> > I noticed your previous discussions about the shadow stack size in the
> > ARM64 GCS patch series. I see that the GCS size was eventually reduced
> > from 4G to 2G.
> >
> > Because the RISC-V shadow stack stores very similar data to GCS, I
> > also reduced the RISC-V shadow stack size to 2G in my recent patch.
> > You can find the reasons for this change here:
> > https://lists.infradead.org/pipermail/linux-riscv/2026-May/091308.html
> >
> > In the same thread, we discussed if we could make the size even
> > smaller. Thank David for his helpful analysis on this topic.
> >
> > Since GCS has been merged for a few years now, we'd like to learn from
> > your experience. We want to make sure we are not missing any important
> > impacts or issues. Therefore, we would really appreciate it if you
> > could share your thoughts with us. This will give us the confidence to
> > move forward with the patch
> >
> > Thanks
> >
> >
> Nobody has reported it causing them a problem, but there's not really
> much practical use yet due to hardware availability so that might change
> and I'm not sure how much inference you can draw there - there is much
> more test use than production use at this stage.  I would be astonished
> if anyone wanted the shadow stack to be bigger, the more likely problem
> is excessive VA usage but we felt it was better to err on the side of
> using too much memory.  The general feedback from userspace people was
> that they weren't too concerned about issues.

Hi Mark,
Sorry for the delayed response; for some reason, your previous email
didn't show up in my inbox. I pasted your message above.

Thank you very much for sharing your valuable experience with GCS.
Based on your insights and our current considerations, Perhaps it is
possible for us to try changing it to 512MB first.This will allow us
to successfully enable the shadow stack on a memory-constrained
platform.

Thanks again for your help!

> >
> > > Suggested-by: David Laight <david.laight.linux@gmail.com>
> > > Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/
> > > Signed-off-by: Zong Li <zong.li@sifive.com>
> > > ---
> > >  arch/riscv/kernel/usercfi.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/riscv/kernel/usercfi.c b/arch/riscv/kernel/usercfi.c
> > > index cbfb4e495e9f..adf97426a906 100644
> > > --- a/arch/riscv/kernel/usercfi.c
> > > +++ b/arch/riscv/kernel/usercfi.c
> > > @@ -110,7 +110,7 @@ void set_indir_lp_lock(struct task_struct *task, bool lock)
> > >  }
> > >  /*
> > >   * The shadow stack only stores the return address and not any variables
> > > - * this should be more than sufficient for most applications.
> > > + * 512M should be more than sufficient for most applications.
> > >   * Else PAGE_ALIGN it and return back
> > >   */
> > >  static unsigned long calc_shstk_size(unsigned long size)
> > > @@ -118,7 +118,7 @@ static unsigned long calc_shstk_size(unsigned long size)
> > >         if (size)
> > >                 return PAGE_ALIGN(size);
> > >
> > > -       return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 2, SZ_2G));
> > > +       return PAGE_ALIGN(min(rlimit(RLIMIT_STACK) / 8, SZ_512M));
> > >  }
> > >
> > >  /*
> > > --
> > > 2.43.7
> > >

Re: [PATCH] riscv: cfi: reduce shadow stack size limit from 2GB to 512MB

[Paul Walmsley]

On Fri, 22 May 2026, Zong Li wrote:

> Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at
> 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's
> analysis and recommendation.
> 
> Rationale:
> 
> David Laight pointed out that the focus should be on the ratio between
> shadow stack size and the normal stack size, rather than just the
> absolute upper limit. His analysis showed that while there are many
> functions with small stack frames, the majority have stack deltas of
> over 64 bytes due to saved registers and local variables.
> 
> Shadow stacks only store return addresses (8 bytes per entry on 64-bit
> systems), whereas normal stack frames typically consume 64+ bytes. This
> 8:64 byte ratio means that programs using a lot of stack space are
> dominated by large buffer allocations and local variables, not extreme
> recursion depths with minimal local data.
> 
> For example, with the default RLIMIT_STACK of 8MB:
> - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls
> - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls
> 
> Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still
> conservative and provides adequate depth for practical applications.
> David noted that this could even be safely halved again.
> 
> This reduction also better accommodates memory-constrained platforms.
> On systems with limited physical memory, allocating large shadow stacks
> can cause virtual memory allocation failures when overcommit mode is set
> to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER.
> 
> Suggested-by: David Laight <david.laight.linux@gmail.com>
> Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/
> Signed-off-by: Zong Li <zong.li@sifive.com>

Thanks, queued for v7.3.


- Paul