From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (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 0EFDE1F4713 for ; Wed, 30 Oct 2024 21:42:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730324565; cv=none; b=nUX7epoM99xjukripIIbO/IOLLm4HNBsiksZvKy+PObNBWfVGDLmJ4EkJ5z2Y4QwHMo+Wgl+idnn1VMhZDLhHVb3W9wk68cBBF9SffbyOQugsPJbK7Me4bB01r7SB2BQsp295IEiSDjtZh/2btOtjRwl9OkmUr81j6Z9UKzQJSQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730324565; c=relaxed/simple; bh=rucg5whNbj0MIf+KsFVqBycgNaOxrJPN8Sa8dKhqJn0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LJpE/lzNlwjh+VQ4Rg0FYzZLILzrYExy4/NDcB5YuGsI6vQ5hPh0u7kbabWEUWqgIRBx64kaBT9ag4QHPKFsz3S/ixMqz32I+mWNCToTKrymWQoh7hQq7EBRJ2dWkEVR16hLEkv0iiUJdZTS53ybo8B8yOWjM499gQ33kqB+1js= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=lsPxMLfj; arc=none smtp.client-ip=209.85.216.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="lsPxMLfj" Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-2e2e2d09decso1099315a91.1 for ; Wed, 30 Oct 2024 14:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1730324562; x=1730929362; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2BdQ8I1/iVHZTqbEU+uI3XwCIW70vWl0AHAkkkOUHa4=; b=lsPxMLfjdqektbm+albSHd1yo/8FqT7xiv9N1GLeNw/v8+SLsNrn2xkGk27y0taG0i wGTm7xRMqMHtMKZn89uMHRi7fbTX4NMKAOhKKpyq3KRVSFIt4yDNNY6MfdAZDmfp/0ot q/BZP7p2MTHXRU/3L9p0MzhxvC87mAYttH4GgY3t0dHsyHf405DXJhHthdTF65KgGtjc PSUBl1Rpe6o0/S8hFZPrDFbW1LHOj0fO78y6NYawPVxvigOLifO7QZBFKubIFqgPXWRB xWO9oecgBfSrJ6At8GEHsrnRvYpJLT3L/D5gKQnPSu+cajYHMVxWCShCfyQng+gBlgsK RT4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730324562; x=1730929362; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2BdQ8I1/iVHZTqbEU+uI3XwCIW70vWl0AHAkkkOUHa4=; b=UlOWcHLdxFnwcjuXsxCtRQsLvZBlYGjVVRxdQCjzpRd9iVoignNr1rRglXHkmZCEOG fhs/e/kJ3zh4FzSUHhAzW+h27Ff+rDckA/Ps1LGeQT47gkWsq5TZFm3YNOdCKEzLySI1 I8D4zXnUJGGbqljyKUTgV1DcNQ5t59opY6e219T2p/K5UM/UA58ZZHoitmpeavw9hP2G VeXoIS/hPAh21UnOS/TcySMixv0tpTS6iCLFMQMnMUOypUjEKVrjozPOflPcmcoUdI0v 394X1ivb5tSVe/pKgf9di70T/PnrV6IqKkW8YPIjFi+WAUnXabEC4K8bDiN16y5/t6+K edhg== X-Forwarded-Encrypted: i=1; AJvYcCWndjDIkiSn1ONQM7TtKqwC29c6cHCCSQXGw6A29S3u02HwTcQURzZuphV09VwsxdX373Cf3jCG1iKXigQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyrOW6L2MuPfsKdu5JpQw1AR7S58QOD0uo41FpTflX2k/s/vYTM ELMu8aPXPd3ajyNvfEq7Lo6VObRcTC3IixQD+rzh+grt37amHYTRpRQlHV3Zcko= X-Google-Smtp-Source: AGHT+IFy/kVyXGrqtNtAvxVjR4gsi2Os3+luFSdpZIwpcWZFvkvKwsZgpNzjHfWBEiMYl3HDGVYUug== X-Received: by 2002:a17:90b:51cc:b0:2e2:af80:8f7a with SMTP id 98e67ed59e1d1-2e93e0fd8f4mr220918a91.20.1730324562278; Wed, 30 Oct 2024 14:42:42 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e92fbe0252sm2400168a91.45.2024.10.30.14.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2024 14:42:41 -0700 (PDT) Date: Wed, 30 Oct 2024 14:42:39 -0700 From: Deepak Gupta To: Mark Brown Cc: "Rick P. Edgecombe" , Szabolcs Nagy , "H.J. Lu" , Florian Weimer , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Christian Brauner , Shuah Khan , linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , jannh@google.com, Yury Khrustalev , Wilco Dijkstra , linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org, Kees Cook , Shuah Khan Subject: Re: [PATCH RFT v11 2/8] Documentation: userspace-api: Add shadow stack API documentation Message-ID: References: <20241005-clone3-shadow-stack-v11-0-2a6a2bd6d651@kernel.org> <20241005-clone3-shadow-stack-v11-2-2a6a2bd6d651@kernel.org> 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20241005-clone3-shadow-stack-v11-2-2a6a2bd6d651@kernel.org> On Sat, Oct 05, 2024 at 11:31:29AM +0100, Mark Brown wrote: >There are a number of architectures with shadow stack features which we are >presenting to userspace with as consistent an API as we can (though there >are some architecture specifics). Especially given that there are some >important considerations for userspace code interacting directly with the >feature let's provide some documentation covering the common aspects. > >Reviewed-by: Catalin Marinas >Reviewed-by: Kees Cook >Tested-by: Kees Cook >Acked-by: Shuah Khan >Signed-off-by: Mark Brown >--- > Documentation/userspace-api/index.rst | 1 + > Documentation/userspace-api/shadow_stack.rst | 41 ++++++++++++++++++++++++++++ > 2 files changed, 42 insertions(+) > >diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst >index 274cc7546efc2a042d2dc00aa67c71c52372179a..c39709bfba2c5682d0d1a22444db17c17bcf01ce 100644 >--- a/Documentation/userspace-api/index.rst >+++ b/Documentation/userspace-api/index.rst >@@ -59,6 +59,7 @@ Everything else > > ELF > netlink/index >+ shadow_stack > sysfs-platform_profile > vduse > futex2 >diff --git a/Documentation/userspace-api/shadow_stack.rst b/Documentation/userspace-api/shadow_stack.rst >new file mode 100644 >index 0000000000000000000000000000000000000000..c576ad3d7ec12f0f75bffa4e2bafd0c9d7230c9f >--- /dev/null >+++ b/Documentation/userspace-api/shadow_stack.rst >@@ -0,0 +1,41 @@ >+============= >+Shadow Stacks >+============= >+ >+Introduction >+============ >+ >+Several architectures have features which provide backward edge >+control flow protection through a hardware maintained stack, only >+writeable by userspace through very limited operations. This feature >+is referred to as shadow stacks on Linux, on x86 it is part of Intel >+Control Enforcement Technology (CET), on arm64 it is Guarded Control >+Stacks feature (FEAT_GCS) and for RISC-V it is the Zicfiss extension. >+It is expected that this feature will normally be managed by the >+system dynamic linker and libc in ways broadly transparent to >+application code, this document covers interfaces and considerations. >+ >+ >+Enabling >+======== >+ >+Shadow stacks default to disabled when a userspace process is >+executed, they can be enabled for the current thread with a syscall: >+ >+ - For x86 the ARCH_SHSTK_ENABLE arch_prctl() I know when you started out, gcs and risc-v shadow stack patches were only catching up. But now that gcs patches are in -next and risc-v patches have also reached some maturity. And considering this generic generic shadow stack documentation, may be it's worth to mention arch agnostic prctls here for shadow stack (that will be used by arm64 and riscv)? What do you think? >+ >+It is expected that this will normally be done by the dynamic linker. >+Any new threads created by a thread with shadow stacks enabled will >+themselves have shadow stacks enabled. >+ >+ >+Enablement considerations >+========================= >+ >+- Returning from the function that enables shadow stacks without first >+ disabling them will cause a shadow stack exception. nit: s/shadow stack exception/arch specific exception indicating control flow violation >+ This includes >+ any syscall wrapper or other library functions, the syscall will need >+ to be inlined. >+- A lock feature allows userspace to prevent disabling of shadow stacks. >+- Those that change the stack context like longjmp() or use of ucontext >+ changes on signal return will need support from libc. > >-- >2.39.2 >