[PATCH v3] riscv: cif: reduce shadow stack size limit from 4GB to 2GB

[Zong Li]

On Sat, May 16, 2026 at 3:16 AM David Laight
<david.laight.linux at gmail.com> wrote:
>
> On Fri, 15 May 2026 22:29:05 +0800
> Zong Li <zong.li at sifive.com> wrote:
>
> > On Fri, May 15, 2026 at 5:24 PM David Laight
> > <david.laight.linux at gmail.com> wrote:
> > >
> > > On Fri, 15 May 2026 11:42:45 +0800
> > > Zong Li <zong.li at sifive.com> wrote:
> > >
> > > > On Thu, May 14, 2026 at 4:56 PM David Laight
> > > ..
> > > > > 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.
> > > >
> > > > During the discussions about the ARM GCS v3 series, community pointed
> > > > out that a 4G shadow stack might be too large. This size is hard to
> > > > support in memory-constrained environments like Android. However, the
> > > > size cannot be too small either, or we might face stack overflow
> > > > issues. At that time, a perfect size was not decided.
> > >
> > > It is only VA not real memory so shouldn't make much difference to memory
> > > use (except for nommu where the actual memory has to be allocated).
> > >
> >
> > You raise a valid point that shadow stacks are primarily a VA
> > allocation. However, in Linux, the memory overcommit mechanism creates
> > a practical link between VA allocation and physical memory capacity.
> > As I mentioned in the commit message, memory allocation will fail when
> > the overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER.
> >
> > In __vm_enough_memory:
> >         if (pages > totalram_pages() + total_swap_pages)
> >                 goto error;
> >
> > Many page requests for VA will fail if the requested size exceeds the
> > system's total RAM plus Swap. On memory-constrained systems,
> > allocating a massive 4GB shadow stack per thread would immediately
> > trigger this error.
>
> But reducing the size by half makes little difference.
> You'd need a much bigger reduction to make any real difference.
>

I agree with you that a smaller size would cover more cases. I am very
open to your ideas regarding the size. Would you prefer to use 1GB or
512MB as the default instead?
As I mentioned in my previous emails, using 2GB seems to be a safe
starting point. This is because it is already accepted by the
community and the Android system (in GCS implementation).
Additionally, although the CFI feature doesn't support 32-bit systems
yet, normal 32-bit systems can only support up to 4GB of physical
memory. If the default shadow stack size is 4GB, it would be almost
impossible to run on a 32-bit system. Using at least 2GB can help
avoid this issue in the future. If you don't have a preferred default
value, maybe we could start with 2G?


> -- David
>
> >
> > > But 32bit programs with lots of threads can run out of VA.
> > > Increasing the stack VA size by 50% might even give problems for 64bit
> > > programs - if they are already reducing the thread stack size avoid
> > > running out of VA.
> > >
> > > I've not checked, but pthread_attr_setstacksize() sets a limit for the
> > > thread stack size (which would otherwise default so rlimit(STACK)).
> > > I don't believe it should update the rlimit value itself.
> > > In which case you are using the wrong size.
> > >
> > > But for a thread with a very reduced stack (say 128k) you probably only
> > > need 1 page of shadow stack, any more could easily lead to running out
> > > of VA.
> > >
> > > -- David
> >
>