From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BA76175A62 for ; Mon, 18 May 2026 09:57:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779098251; cv=none; b=BvXB1dMUbdWKiCuT4wSOSMfyyo/012EpogFk4lymqsVZ+Nswjw8oYTN0nPkjz3v1kVzwM8Nmg7WKyVYGoYo41z5QsksxDIk8nVXP4q0S7cXcBpSX5yNVV4K/KqtchZtlQ5Gl1q3ZhlwVOVLnCnIj8VjwLO2RC/qznNky3cPklog= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779098251; c=relaxed/simple; bh=1/SwIiA5aU2s7wXzzcGa+fBfKjwCMi7XmJtyNR0b2Vs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RvxE2TFLU8pyG9ZqBXuGEPyA9p0ce4CtxPrAocsj2pasiEQBOjjMsstxCNAML2tIYzPt1srzhnPfNzMuyzYOCZcV9rns8yQ9CJWIBjybFLr8eH/LUVeHngoI0uWj5yxdteXwS2QnbcBg7DfPGBKBHZQFJoW6pFpA9DwmL2FwxG0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KWMwacne; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KWMwacne" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-44a14580111so1504331f8f.0 for ; Mon, 18 May 2026 02:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779098247; x=1779703047; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=HT0Lf2/mFgKxOu+qdEtEaudYEyue/pxbGLR/tX7Yu8c=; b=KWMwacnedd1XT5HxG8atZvqDIFBZmVL1FNUeSQgqks8v8ridooiaMW0Qd03PwARUCe zu2xBEiiRIslDzgmHLyVgFsUBOtZLIVqqzppCWbMuL77ZCyxiHCjSLn4ybnfbFebUSu/ 6hwOot+rYiLqNAUda28SGK/Hwb+yxHVcnjNpeG8JAGy1DRRPi+5tY3rUS0gF9RcUxx6U A+x3Otb79KkOkDcATIWAQLa6UGPVfV7YkthHTiiPoqN/2DRBVCdmT6ntVJgeGFGpQNNv R4Lg6dxDvPFl4uWR2/1rDsu61giCUpEbuh+nV90Kcv82yE++ohcCDO/v1QCJilYvxHSZ 0M2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779098247; x=1779703047; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=HT0Lf2/mFgKxOu+qdEtEaudYEyue/pxbGLR/tX7Yu8c=; b=KIBnx6TRk4dx9hPu+JsYn3HKl41MCjK0zlxLD1Zr92448MfjCgluAG8Y5B7Z9rXIe+ 6jmFkwcBn2KCnjsoX8niDv1XWy6pF9k5BbZFlVbKQOz1PxlC/JbglYosQkQG7+p5zr/3 YleevFV/FQgH0TwrLOj/+TORmenj0ulhOrE5CFUKQzMW405K7GHzhwV24a5qaM8+vfBs 1mf25E052Vu77r124vsQWz5aM0GRsksWJMjzei5ySCQ7HrO7Yo87B45xmPfzuNV2/bam EPfKJ1wH9C6Ezw3nB6VvmKQVhIR06Ud95LXhMkfuz0vpoHiww5vCHqSLINzz+VKbJfun UlBQ== X-Forwarded-Encrypted: i=1; AFNElJ+mOgj+J/6i5H3Rlmk6RXqLis7APZFbZtw2MCl7+Bcx5UDnIZKueN1y5bmLvFNmuWtZJRow3XOd/IqHdiM=@vger.kernel.org X-Gm-Message-State: AOJu0YzcDevvV7vRr38fVWyLKtrDelNWTmbNm7pv++Nj01gJW1VTF6Xe oQTM6ZySmH+XfmNVPSXgLGwR/XN4aPx2bCG5wcgJL5r90WiygBKnOX+V X-Gm-Gg: Acq92OHFMbYOuykYT4vAutdpMYmppuJT8wmj3XUk5pytI09Jue6Bx8zJv2I9U/ZHT3T g4CLhO0HGI1G5vGhBru7b/fG97oK1kS4+MRWJY947Ueo6xXI9cCoeBr8X32zBQ0rCxiYEEOOWNa ncJ0VXl2D0v7RPIqo7N0dJOqa76gm/PhvEYk9SdGZlD40//xL3daE2UuwG1/xgw+Xxve2bh9sum RxycUnbzHk753TQbJNf8WHAncckROGVDPB/VE8n7t9OVx4C0yCXQViRhwi6odoa43m1GBQlB9cJ 72LUzGY9TCUmycqrr3Hv48fhKXDoVkpcGnOBpCI9+Lq9OTcXUXP5b5CJW12ABMFibNwqGJp49kL DtL49I1GTGBAmTY3Wp6zFcMb/vmSTVljJ0JyJkIyQF1C94D5LUhc2IPfYZFE1vqF6VLTlP+exZm lArToSSz31uh+V81P3nqjTC5+ABWNB5NUy5BlR710giFWUTJyWyij0FawFkL5ePUDadTz3qTEim O0= X-Received: by 2002:a05:6000:2304:b0:441:1c95:17e7 with SMTP id ffacd0b85a97d-45e5c5c9e11mr23052887f8f.15.1779098247199; Mon, 18 May 2026 02:57:27 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da0a19a0csm34266191f8f.20.2026.05.18.02.57.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 02:57:26 -0700 (PDT) Date: Mon, 18 May 2026 10:57:25 +0100 From: David Laight To: Zong Li 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 Message-ID: <20260518105725.7afe7a4c@pumpkin> In-Reply-To: References: <20260514075036.1432352-1-zong.li@sifive.com> <20260514095605.2c7d8761@pumpkin> <20260515102411.4d3e868a@pumpkin> <20260515201613.243ea49b@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 18 May 2026 11:54:32 +0800 Zong Li wrote: > On Sat, May 16, 2026 at 3:16=E2=80=AFAM David Laight > wrote: > > > > On Fri, 15 May 2026 22:29:05 +0800 > > Zong Li wrote: > > =20 > > > On Fri, May 15, 2026 at 5:24=E2=80=AFPM David Laight > > > wrote: =20 > > > > > > > > On Fri, 15 May 2026 11:42:45 +0800 > > > > Zong Li wrote: > > > > =20 > > > > > On Thu, May 14, 2026 at 4:56=E2=80=AFPM David Laight =20 > > > > .. =20 > > > > > > I also don't understand the rational for just /2 and the 2G upp= er limit. > > > > > > You need 512 nested function calls to even use 4k. > > > > > > That would have to be quite deep recursion. =20 > > > > > > > > > > During the discussions about the ARM GCS v3 series, community poi= nted > > > > > 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. =20 > > > > > > > > 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). > > > > =20 > > > > > > 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. =20 > > > > But reducing the size by half makes little difference. > > You'd need a much bigger reduction to make any real difference. > > =20 >=20 > 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? I've no real idea - note that the rlimit value should be small for 32bit (or at least the actual stack is small regardless of the rlimit value). The 2G is just an upper bound - probably matching the 4G upper bound for the 64bit stack itself. Don't focus on the 2G limit, but on the rlimit(STACK)/2 (or rather the size of the normal stack). On my systems the default soft limit is 8M, a 4M shadow stack supports 512k nested function calls (64bit) - none of which can have any local data. In reality programs that use a lot of stack allocate large buffers on stack, they don't have silly depths of recursive functions with no local data. I've just looked at vmlinux.o - which won't be representative of userspace! While there are a lot of functions with small stack frame (sub $0x10,%rsp) they tend to have saved a few registers in stack first. The majority will have a stack delta of over 64 bytes. That corresponds to rlimit(STACK)/8 and even that is conservative. I'd suspect that could safely halve that again. Actually would it be possible to initially just allocate one page? If you get an overflow fault on the shadow stack I think you can safely reallocate it at an entirely different user virtual address. That would remove all the problems over committing a lot of swap. Most threads will never do the 512 nested calls needed to blow the stack. -- David >=20 >=20 > > -- David > > =20 > > > =20 > > > > But 32bit programs with lots of threads can run out of VA. > > > > Increasing the stack VA size by 50% might even give problems for 64= bit > > > > 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 =20 > > > =20 > > =20