[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241016-shstk_converge-v2-0-c41536eb5c3b@rivosinc.com>
Date: Wed, 16 Oct 2024 14:57:32 -0700
From: Deepak Gupta <debug@...osinc.com>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-arch@...r.kernel.org,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
Mark Brown <broonie@...nel.org>, Deepak Gupta <debug@...osinc.com>
Subject: [PATCH RFC/RFT v2 0/2] Converge common flows for cpu assisted
shadow stack
x86, arm64 and risc-v support cpu assisted shadow stack. x86 was first
one and most of the shadow stack related code is in x86 arch directory.
arm64 guarded control stack (GCS) patches from Mark Brown are in -next.
This led to obvious discussion many how to merge certain common flows in
generic code. Recent one being [1]. Goes without saying having generic
code helps with bug management as well (not having to fix same bug for 3
different arches).
High level common flow between x86, riscv and arm64:
- Enabling is via prctl.
Enabling and book keeping per task_struct in thread data strutures
differ on each architecture. This version of patchset doesn't
try to merge those flows.
- Managing virtual memory for shadow stack handled similarly.
From kernel's perspective shadow stack writeable memory which can be
written by only certain selected store operations (depending on arch)
This patch converges this notion between different architecture to
allocate, map and free shadow stack.
- Virtual memory management of shadow stack on clone/fork is similar.
Treatment of copy-on-write (COW) or using parent's stack (CLONE_VFORK)
or allocating new shadow stack (CLONE_VM) are similar in all arch.
Thus logic to setup shadow stack should be similar on clone/fork
Mark brown introduced `ARCH_HAS_SHADOW_STACK` as part of arm64 gcs series
[2] and this patch set depends on it. This patchset uses same config to
move as much as possible common code in generic kernel. Additionaly this
patchset introduces wrapper abstractions where arch specific handling is
required.
Generic code and arch specific code for shadow stack are independent
modules and can call into each other. This is by design because each
architecture's enabling mechanisms are different but at the same time
from kernel's perspective it's a special memory which is writeable from
certain selected store operations.
I've not tested this. Only compiled for x86 with shadow stack enable. Thus
this is a RFC and possible looking for some help to test as well on x86.
[1] - https://lore.kernel.org/all/20241008-v5_user_cfi_series-v6-0-60d9fe073f37@rivosinc.com/T/#m98d14237663150778a3f8df59a76a3fe6318624a
[2] - https://lore.kernel.org/linux-arm-kernel/20241001-arm64-gcs-v13-0-222b78d87eee@kernel.org/T/#m1ff65a49873b0e770e71de7af178f581c72be7ad
To: Thomas Gleixner <tglx@...utronix.de>
To: Ingo Molnar <mingo@...hat.com>
To: Borislav Petkov <bp@...en8.de>
To: Dave Hansen <dave.hansen@...ux.intel.com>
To: x86@...nel.org
To: H. Peter Anvin <hpa@...or.com>
To: Andrew Morton <akpm@...ux-foundation.org>
To: Liam R. Howlett <Liam.Howlett@...cle.com>
To: Vlastimil Babka <vbabka@...e.cz>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org
Cc: linux-fsdevel@...r.kernel.org
Cc: linux-mm@...ck.org
Cc: linux-arch@...r.kernel.org
Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>
Cc: Mark Brown <broonie@...nel.org>
Signed-off-by: Deepak Gupta <debug@...osinc.com>
---
Changes in v2:
- Doesn't carry patch which introduces `ARCH_HAS_SHADOW_STACK`. Most likely
it'll be merged as part of arm64 gcs patch series.
- moves shstk_setup back into x86 portion. Primary reason is that entire arch
specific prctl specific handling can't be made generic easily due to arch
differences.
- Due to prctl handling code remaining arch specific, removed generic wrappers
to set thread status and shstk enabling
- Removed x86 specific comment
- Added `SHADOW_STACK_SET_MARKER`
- Link to v1: https://lore.kernel.org/r/20241010-shstk_converge-v1-0-631beca676e7@rivosinc.com
---
Deepak Gupta (2):
mm: helper `is_shadow_stack_vma` to check shadow stack vma
kernel: converge common shadow stack flow agnostic to arch
arch/x86/include/asm/shstk.h | 7 +
arch/x86/include/uapi/asm/mman.h | 3 -
arch/x86/kernel/shstk.c | 223 +++++---------------------------
include/linux/usershstk.h | 22 ++++
include/uapi/asm-generic/mman-common.h | 5 +
kernel/Makefile | 2 +
kernel/usershstk.c | 230 +++++++++++++++++++++++++++++++++
mm/gup.c | 2 +-
mm/mmap.c | 2 +-
mm/vma.h | 10 +-
10 files changed, 305 insertions(+), 201 deletions(-)
---
base-commit: 4e0105ad0161b4262b51f034a757c4899c647487
change-id: 20241010-shstk_converge-aefbcbef5d71
--
- debug
Powered by blists - more mailing lists