[RFC/RFT,v2,0/2] Converge common flows for cpu assisted shadow stack

Message

Deepak Gupta Oct. 16, 2024, 9:57 p.m. UTC

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/[e-mail]/T/#m98d14237663150778a3f8df59a76a3fe6318624a
[2] - https://lore.kernel.org/linux-arm-kernel/[e-mail]/T/#m1ff65a49873b0e770e71de7af178f581c72be7ad

To: Thomas Gleixner <[e-mail]>
To: Ingo Molnar <[e-mail]>
To: Borislav Petkov <[e-mail]>
To: Dave Hansen <[e-mail]>
To: [e-mail]
To: H. Peter Anvin <[e-mail]>
To: Andrew Morton <[e-mail]>
To: Liam R. Howlett <[e-mail]>
To: Vlastimil Babka <[e-mail]>
To: Lorenzo Stoakes <[e-mail]>
To: Arnd Bergmann <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: Rick Edgecombe <[e-mail]>
Cc: Mark Brown <[e-mail]>

Signed-off-by: Deepak Gupta <[e-mail]>
---
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/[e-mail]

---
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

Comments

Edgecombe, Rick P Nov. 1, 2024, 9:47 p.m. UTC | #1

On Wed, 2024-10-16 at 14:57 -0700, Deepak Gupta wrote:
> ---
> base-commit: 4e0105ad0161b4262b51f034a757c4899c647487
> change-id: 20241010-shstk_converge-aefbcbef5d71

Where can I find this base commit?

Deepak Gupta Nov. 14, 2024, 11:15 p.m. UTC | #2

On Fri, Nov 01, 2024 at 09:47:31PM +0000, Edgecombe, Rick P wrote:
>On Wed, 2024-10-16 at 14:57 -0700, Deepak Gupta wrote:
>> ---
>> base-commit: 4e0105ad0161b4262b51f034a757c4899c647487
>> change-id: 20241010-shstk_converge-aefbcbef5d71
>
>Where can I find this base commit?

I am sorry. I picked up Mark's "mm: Introduce ARCH_HAS_USER_SHADOW_STACK"
locally and then created patches.

Should have rebased with arm64/for-next.
But for that as well base commit will be on arm64/for-next.

You can apply "mm: Introduce ARCH_HAS_USER_SHADOW_STACK" on "v6.12-rc1"
and then these patches.

Alternatively I can send a v3 with above patch.

Mark Brown Nov. 15, 2024, 2:17 p.m. UTC | #3

On Thu, Nov 14, 2024 at 03:15:41PM -0800, Deepak Gupta wrote:

> Alternatively I can send a v3 with above patch.

I guess at this point it's probably as well to just rebase onto
v6.13-rc1 when that appears, that should have the GCS series in it and
it's probably worth rebasing/resending when that comes out anyway.