mbox series

[v3,00/25] Permission Overlay Extension

Message ID 20231124163510.1835740-1-joey.gouly@arm.com (mailing list archive)
Headers show
Series Permission Overlay Extension | expand

Message

Joey Gouly Nov. 24, 2023, 4:34 p.m. UTC
Hello everyone,

This series implements the Permission Overlay Extension introduced in 2022
VMSA enhancements [1]. It is based on v6.7-rc2.

Changes since v2[2]:
	# Added ptrace support and selftest
	# Add missing POR_EL0 initialisation in fork/clone
	# Rebase onto v6.7-rc2
	# Add r-bs

The Permission Overlay Extension allows to constrain permissions on memory
regions. This can be used from userspace (EL0) without a system call or TLB
invalidation.

POE is used to implement the Memory Protection Keys [3] Linux syscall.

The first few patches add the basic framework, then the PKEYS interface is
implemented, and then the selftests are made to work on arm64.

There was discussion about what the 'default' protection key value should be,
I used disallow-all (apart from pkey 0), which matches what x86 does.

I have tested the modified protection_keys test on x86_64, but not PPC.
I haven't build tested the x86/ppc arch changes.

Thanks,
Joey

[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022
[2] https://lore.kernel.org/linux-arm-kernel/20231027180850.1068089-1-joey.gouly@arm.com/
[3] Documentation/core-api/protection-keys.rst

Joey Gouly (25):
  arm64/sysreg: add system register POR_EL{0,1}
  arm64/sysreg: update CPACR_EL1 register
  arm64: cpufeature: add Permission Overlay Extension cpucap
  arm64: disable trapping of POR_EL0 to EL2
  arm64: context switch POR_EL0 register
  KVM: arm64: Save/restore POE registers
  arm64: enable the Permission Overlay Extension for EL0
  arm64: add POIndex defines
  arm64: define VM_PKEY_BIT* for arm64
  arm64: mask out POIndex when modifying a PTE
  arm64: enable ARCH_HAS_PKEYS on arm64
  arm64: handle PKEY/POE faults
  arm64: stop using generic mm_hooks.h
  arm64: implement PKEYS support
  arm64: add POE signal support
  arm64: enable PKEY support for CPUs with S1POE
  arm64: enable POE and PIE to coexist
  arm64/ptrace: add support for FEAT_POE
  kselftest/arm64: move get_header()
  selftests: mm: move fpregs printing
  selftests: mm: make protection_keys test work on arm64
  kselftest/arm64: add HWCAP test for FEAT_S1POE
  kselftest/arm64: parse POE_MAGIC in a signal frame
  kselftest/arm64: Add test case for POR_EL0 signal frame records
  KVM: selftests: get-reg-list: add Permission Overlay registers

 Documentation/arch/arm64/elf_hwcaps.rst       |   3 +
 arch/arm64/Kconfig                            |  18 +++
 arch/arm64/include/asm/cpufeature.h           |   6 +
 arch/arm64/include/asm/el2_setup.h            |  10 +-
 arch/arm64/include/asm/hwcap.h                |   1 +
 arch/arm64/include/asm/kvm_arm.h              |   4 +-
 arch/arm64/include/asm/kvm_host.h             |   4 +
 arch/arm64/include/asm/mman.h                 |   8 +-
 arch/arm64/include/asm/mmu.h                  |   2 +
 arch/arm64/include/asm/mmu_context.h          |  51 ++++++-
 arch/arm64/include/asm/page.h                 |  10 ++
 arch/arm64/include/asm/pgtable-hwdef.h        |  10 ++
 arch/arm64/include/asm/pgtable-prot.h         |   8 +-
 arch/arm64/include/asm/pgtable.h              |  26 +++-
 arch/arm64/include/asm/pkeys.h                | 110 ++++++++++++++
 arch/arm64/include/asm/por.h                  |  33 +++++
 arch/arm64/include/asm/processor.h            |   1 +
 arch/arm64/include/asm/sysreg.h               |  16 ++
 arch/arm64/include/asm/traps.h                |   1 +
 arch/arm64/include/uapi/asm/hwcap.h           |   1 +
 arch/arm64/include/uapi/asm/sigcontext.h      |   7 +
 arch/arm64/kernel/cpufeature.c                |  23 +++
 arch/arm64/kernel/cpuinfo.c                   |   1 +
 arch/arm64/kernel/process.c                   |  22 +++
 arch/arm64/kernel/ptrace.c                    |  46 ++++++
 arch/arm64/kernel/signal.c                    |  51 +++++++
 arch/arm64/kernel/traps.c                     |  12 +-
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h    |  10 ++
 arch/arm64/kvm/sys_regs.c                     |   2 +
 arch/arm64/mm/fault.c                         |  44 +++++-
 arch/arm64/mm/mmap.c                          |   9 ++
 arch/arm64/mm/mmu.c                           |  40 +++++
 arch/arm64/tools/cpucaps                      |   1 +
 arch/arm64/tools/sysreg                       |  15 +-
 arch/powerpc/include/asm/page.h               |  11 ++
 arch/x86/include/asm/page.h                   |  10 ++
 fs/proc/task_mmu.c                            |   2 +
 include/linux/mm.h                            |  13 --
 include/uapi/linux/elf.h                      |   1 +
 tools/testing/selftests/arm64/abi/hwcap.c     |  14 ++
 .../testing/selftests/arm64/signal/.gitignore |   1 +
 .../arm64/signal/testcases/poe_siginfo.c      |  86 +++++++++++
 .../arm64/signal/testcases/testcases.c        |  27 +---
 .../arm64/signal/testcases/testcases.h        |  28 +++-
 .../selftests/kvm/aarch64/get-reg-list.c      |  14 ++
 tools/testing/selftests/mm/Makefile           |   2 +-
 tools/testing/selftests/mm/pkey-arm64.h       | 139 ++++++++++++++++++
 tools/testing/selftests/mm/pkey-helpers.h     |   8 +
 tools/testing/selftests/mm/pkey-powerpc.h     |   3 +
 tools/testing/selftests/mm/pkey-x86.h         |   4 +
 tools/testing/selftests/mm/protection_keys.c  | 109 ++++++++++++--
 51 files changed, 1011 insertions(+), 67 deletions(-)
 create mode 100644 arch/arm64/include/asm/pkeys.h
 create mode 100644 arch/arm64/include/asm/por.h
 create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_siginfo.c
 create mode 100644 tools/testing/selftests/mm/pkey-arm64.h

Comments

Marc Zyngier Dec. 4, 2023, 11:03 a.m. UTC | #1
Hi Joey,

On Fri, 24 Nov 2023 16:34:45 +0000,
Joey Gouly <joey.gouly@arm.com> wrote:
> 
> Hello everyone,
> 
> This series implements the Permission Overlay Extension introduced in 2022
> VMSA enhancements [1]. It is based on v6.7-rc2.
> 
> Changes since v2[2]:
> 	# Added ptrace support and selftest
> 	# Add missing POR_EL0 initialisation in fork/clone
> 	# Rebase onto v6.7-rc2
> 	# Add r-bs
> 
> The Permission Overlay Extension allows to constrain permissions on memory
> regions. This can be used from userspace (EL0) without a system call or TLB
> invalidation.

I have given this series a few more thoughts, and came to the
conclusion that is it still incomplete on the KVM front:

* FEAT_S1POE often comes together with FEAT_S2POE. For obvious
  reasons, we cannot afford to let the guest play with S2POR_EL1, nor
  do we want to advertise FEAT_S2POE to the guest.

  You will need to add some additional FGT for this, and mask out
  FEAT_S2POE from the guest's view of the ID registers.

* letting the guest play with POE comes with some interesting strings
  attached: a guest that has started on a POE-enabled host cannot be
  migrated to one that doesn't have POE. which means that the POE
  registers should only be visible to the host userspace if enabled in
  the guest's ID registers, and thus only context-switched in these
  conditions. They should otherwise UNDEF.

Thanks,

	M.
Joey Gouly Dec. 5, 2023, 3:41 p.m. UTC | #2
Hi Marc,

On Mon, Dec 04, 2023 at 11:03:24AM +0000, Marc Zyngier wrote:
> Hi Joey,
> 
> On Fri, 24 Nov 2023 16:34:45 +0000,
> Joey Gouly <joey.gouly@arm.com> wrote:
> > 
> > Hello everyone,
> > 
> > This series implements the Permission Overlay Extension introduced in 2022
> > VMSA enhancements [1]. It is based on v6.7-rc2.
> > 
> > Changes since v2[2]:
> > 	# Added ptrace support and selftest
> > 	# Add missing POR_EL0 initialisation in fork/clone
> > 	# Rebase onto v6.7-rc2
> > 	# Add r-bs
> > 
> > The Permission Overlay Extension allows to constrain permissions on memory
> > regions. This can be used from userspace (EL0) without a system call or TLB
> > invalidation.
> 
> I have given this series a few more thoughts, and came to the
> conclusion that is it still incomplete on the KVM front:
> 
> * FEAT_S1POE often comes together with FEAT_S2POE. For obvious
>   reasons, we cannot afford to let the guest play with S2POR_EL1, nor
>   do we want to advertise FEAT_S2POE to the guest.
> 
>   You will need to add some additional FGT for this, and mask out
>   FEAT_S2POE from the guest's view of the ID registers.

I found out last week that I had misunderstood S2POR_EL1, so yes looks like
we need to trap that. I will add that in.

> 
> * letting the guest play with POE comes with some interesting strings
>   attached: a guest that has started on a POE-enabled host cannot be
>   migrated to one that doesn't have POE. which means that the POE
>   registers should only be visible to the host userspace if enabled in
>   the guest's ID registers, and thus only context-switched in these
>   conditions. They should otherwise UNDEF.

Can you give me some clarification here?
	
	- By visible to the host userspace do you mean via the GET_ONE_REG API?
	- Currently the ID register (ID_AA64MMFR3_EL1) is not ID_WRITABLE,
	  should this series or another make it so? Currently if the host had
	  POE it's enabled in the guest, so I believe migration to a non-POE
	  host will fail?
	- For the context switch, do you mean something like:

		if (system_supports_poe() && ID_REG(MMFR3_EL1) & S1POE)
			ctxt_sys_reg(ctxt, POR_EL0)     = read_sysreg_s(SYS_POR_EL0);

	  That would need some refactoring, since I don't see how to access
	  id_regs from struct kvm_cpu_context.

Thanks,
Joey