All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/10] arm64: BTI kernel and vDSO support
@ 2020-04-15 13:07 Mark Brown
  2020-04-15 13:07 ` [PATCH 01/10] arm64: kernel: Convert to modern annotations for assembly functions Mark Brown
                   ` (10 more replies)
  0 siblings, 11 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

This patch series builds on top of a merge of for-next/bti in the arm64
tree and v5.7-rc1 to add support for protecting the kernel and vDSO with
BTI.  It does not currently handle BPF, that will be added in a future
update.

We build the kernel with annotations for BTI and then map the kernel
with GP based on the support on the boot CPU, rejecting secondaries that
don't have BTI support.  If there is a need to handle big.LITTLE systems
with mismatched BTI support we will have to revisit this, currently no
such implementations exist.

Due to code generation issues with current versions of GCC we currently
disable this support when building with GCC, these issues are under
active investigation and once fixes are understood we can add suitable
dependencies.

Mark Brown (10):
  arm64: kernel: Convert to modern annotations for assembly functions
  arm64: bti: Support building kernel C code using BTI
  arm64: asm: Override SYM_FUNC_START when building the kernel with BTI
  arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  arm64: mm: Mark module text as guarded pages
  arm64: bti: Provide Kconfig for kernel mode BTI
  arm64: asm: Provide a mechanism for generating ELF note for BTI
  arm64: vdso: Annotate for BTI
  arm64: vdso: Force the vDSO to be linked as BTI when built for BTI
  arm64: vdso: Map the vDSO text with guarded pages when built for BTI

 arch/arm64/Kconfig                            | 18 ++++++++
 arch/arm64/Makefile                           |  4 ++
 arch/arm64/include/asm/assembler.h            | 41 +++++++++++++++++
 arch/arm64/include/asm/linkage.h              | 46 +++++++++++++++++++
 arch/arm64/include/asm/pgtable-prot.h         |  5 ++
 arch/arm64/kernel/cpu-reset.S                 |  4 +-
 arch/arm64/kernel/cpufeature.c                |  4 ++
 arch/arm64/kernel/efi-rt-wrapper.S            |  4 +-
 arch/arm64/kernel/entry-fpsimd.S              | 20 ++++----
 arch/arm64/kernel/entry.S                     |  7 +--
 arch/arm64/kernel/hibernate-asm.S             | 16 +++----
 arch/arm64/kernel/hyp-stub.S                  | 20 ++++----
 arch/arm64/kernel/probes/kprobes_trampoline.S |  4 +-
 arch/arm64/kernel/reloc_test_syms.S           | 44 +++++++++---------
 arch/arm64/kernel/relocate_kernel.S           |  4 +-
 arch/arm64/kernel/sleep.S                     | 12 ++---
 arch/arm64/kernel/smccc-call.S                |  8 ++--
 arch/arm64/kernel/vdso.c                      |  6 ++-
 arch/arm64/kernel/vdso/Makefile               |  4 +-
 arch/arm64/kernel/vdso/note.S                 |  3 ++
 arch/arm64/kernel/vdso/sigreturn.S            |  3 ++
 arch/arm64/kernel/vdso/vdso.S                 |  3 ++
 arch/arm64/mm/mmu.c                           | 24 ++++++++++
 arch/arm64/mm/pageattr.c                      |  4 +-
 24 files changed, 233 insertions(+), 75 deletions(-)

-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 01/10] arm64: kernel: Convert to modern annotations for assembly functions
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 02/10] arm64: bti: Support building kernel C code using BTI Mark Brown
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

In an effort to clarify and simplify the annotation of assembly functions
in the kernel new macros have been introduced. These replace ENTRY and
ENDPROC and also add a new annotation for static functions which previously
had no ENTRY equivalent. Update the annotations in the core kernel code to
the new macros.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/cpu-reset.S                 |  4 +-
 arch/arm64/kernel/efi-rt-wrapper.S            |  4 +-
 arch/arm64/kernel/entry-fpsimd.S              | 20 ++++-----
 arch/arm64/kernel/entry.S                     |  7 +--
 arch/arm64/kernel/hibernate-asm.S             | 16 +++----
 arch/arm64/kernel/hyp-stub.S                  | 20 ++++-----
 arch/arm64/kernel/probes/kprobes_trampoline.S |  4 +-
 arch/arm64/kernel/reloc_test_syms.S           | 44 +++++++++----------
 arch/arm64/kernel/relocate_kernel.S           |  4 +-
 arch/arm64/kernel/sleep.S                     | 12 ++---
 arch/arm64/kernel/smccc-call.S                |  8 ++--
 11 files changed, 72 insertions(+), 71 deletions(-)

diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 38087b4c0432..646103743a50 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -29,7 +29,7 @@
  * branch to what would be the reset vector. It must be executed with the
  * flat identity mapping.
  */
-ENTRY(__cpu_soft_restart)
+SYM_FUNC_START(__cpu_soft_restart)
 	/* Clear sctlr_el1 flags. */
 	mrs	x12, sctlr_el1
 	mov_q	x13, SCTLR_ELx_FLAGS
@@ -47,6 +47,6 @@ ENTRY(__cpu_soft_restart)
 	mov	x1, x3				// arg1
 	mov	x2, x4				// arg2
 	br	x8
-ENDPROC(__cpu_soft_restart)
+SYM_FUNC_END(__cpu_soft_restart)
 
 .popsection
diff --git a/arch/arm64/kernel/efi-rt-wrapper.S b/arch/arm64/kernel/efi-rt-wrapper.S
index 3fc71106cb2b..1192c4bb48df 100644
--- a/arch/arm64/kernel/efi-rt-wrapper.S
+++ b/arch/arm64/kernel/efi-rt-wrapper.S
@@ -5,7 +5,7 @@
 
 #include <linux/linkage.h>
 
-ENTRY(__efi_rt_asm_wrapper)
+SYM_FUNC_START(__efi_rt_asm_wrapper)
 	stp	x29, x30, [sp, #-32]!
 	mov	x29, sp
 
@@ -35,4 +35,4 @@ ENTRY(__efi_rt_asm_wrapper)
 	b.ne	0f
 	ret
 0:	b	efi_handle_corrupted_x18	// tail call
-ENDPROC(__efi_rt_asm_wrapper)
+SYM_FUNC_END(__efi_rt_asm_wrapper)
diff --git a/arch/arm64/kernel/entry-fpsimd.S b/arch/arm64/kernel/entry-fpsimd.S
index 0f24eae8f3cc..f880dd63ddc3 100644
--- a/arch/arm64/kernel/entry-fpsimd.S
+++ b/arch/arm64/kernel/entry-fpsimd.S
@@ -16,34 +16,34 @@
  *
  * x0 - pointer to struct fpsimd_state
  */
-ENTRY(fpsimd_save_state)
+SYM_FUNC_START(fpsimd_save_state)
 	fpsimd_save x0, 8
 	ret
-ENDPROC(fpsimd_save_state)
+SYM_FUNC_END(fpsimd_save_state)
 
 /*
  * Load the FP registers.
  *
  * x0 - pointer to struct fpsimd_state
  */
-ENTRY(fpsimd_load_state)
+SYM_FUNC_START(fpsimd_load_state)
 	fpsimd_restore x0, 8
 	ret
-ENDPROC(fpsimd_load_state)
+SYM_FUNC_END(fpsimd_load_state)
 
 #ifdef CONFIG_ARM64_SVE
-ENTRY(sve_save_state)
+SYM_FUNC_START(sve_save_state)
 	sve_save 0, x1, 2
 	ret
-ENDPROC(sve_save_state)
+SYM_FUNC_END(sve_save_state)
 
-ENTRY(sve_load_state)
+SYM_FUNC_START(sve_load_state)
 	sve_load 0, x1, x2, 3, x4
 	ret
-ENDPROC(sve_load_state)
+SYM_FUNC_END(sve_load_state)
 
-ENTRY(sve_get_vl)
+SYM_FUNC_START(sve_get_vl)
 	_sve_rdvl	0, 1
 	ret
-ENDPROC(sve_get_vl)
+SYM_FUNC_END(sve_get_vl)
 #endif /* CONFIG_ARM64_SVE */
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index ddcde093c433..664a833aa619 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -730,7 +730,7 @@ SYM_CODE_END(el0_error)
 /*
  * Ok, we need to do extra processing, enter the slow path.
  */
-work_pending:
+SYM_CODE_START_LOCAL(work_pending)
 	mov	x0, sp				// 'regs'
 	bl	do_notify_resume
 #ifdef CONFIG_TRACE_IRQFLAGS
@@ -738,10 +738,11 @@ work_pending:
 #endif
 	ldr	x1, [tsk, #TSK_TI_FLAGS]	// re-check for single-step
 	b	finish_ret_to_user
+SYM_CODE_END(work_pending)
 /*
  * "slow" syscall return path.
  */
-ret_to_user:
+SYM_CODE_START_LOCAL(ret_to_user)
 	disable_daif
 	gic_prio_kentry_setup tmp=x3
 	ldr	x1, [tsk, #TSK_TI_FLAGS]
@@ -753,7 +754,7 @@ finish_ret_to_user:
 	bl	stackleak_erase
 #endif
 	kernel_exit 0
-ENDPROC(ret_to_user)
+SYM_CODE_END(ret_to_user)
 
 	.popsection				// .entry.text
 
diff --git a/arch/arm64/kernel/hibernate-asm.S b/arch/arm64/kernel/hibernate-asm.S
index 6532105b3e32..8ccca660034e 100644
--- a/arch/arm64/kernel/hibernate-asm.S
+++ b/arch/arm64/kernel/hibernate-asm.S
@@ -65,7 +65,7 @@
  * x5: physical address of a  zero page that remains zero after resume
  */
 .pushsection    ".hibernate_exit.text", "ax"
-ENTRY(swsusp_arch_suspend_exit)
+SYM_CODE_START(swsusp_arch_suspend_exit)
 	/*
 	 * We execute from ttbr0, change ttbr1 to our copied linear map tables
 	 * with a break-before-make via the zero page
@@ -110,7 +110,7 @@ ENTRY(swsusp_arch_suspend_exit)
 	cbz	x24, 3f		/* Do we need to re-initialise EL2? */
 	hvc	#0
 3:	ret
-ENDPROC(swsusp_arch_suspend_exit)
+SYM_CODE_END(swsusp_arch_suspend_exit)
 
 /*
  * Restore the hyp stub.
@@ -119,15 +119,15 @@ ENDPROC(swsusp_arch_suspend_exit)
  *
  * x24: The physical address of __hyp_stub_vectors
  */
-el1_sync:
+SYM_CODE_START_LOCAL(el1_sync)
 	msr	vbar_el2, x24
 	eret
-ENDPROC(el1_sync)
+SYM_CODE_END(el1_sync)
 
 .macro invalid_vector	label
-\label:
+SYM_CODE_START_LOCAL(\label)
 	b \label
-ENDPROC(\label)
+SYM_CODE_END(\label)
 .endm
 
 	invalid_vector	el2_sync_invalid
@@ -141,7 +141,7 @@ ENDPROC(\label)
 
 /* el2 vectors - switch el2 here while we restore the memory image. */
 	.align 11
-ENTRY(hibernate_el2_vectors)
+SYM_CODE_START(hibernate_el2_vectors)
 	ventry	el2_sync_invalid		// Synchronous EL2t
 	ventry	el2_irq_invalid			// IRQ EL2t
 	ventry	el2_fiq_invalid			// FIQ EL2t
@@ -161,6 +161,6 @@ ENTRY(hibernate_el2_vectors)
 	ventry	el1_irq_invalid			// IRQ 32-bit EL1
 	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
 	ventry	el1_error_invalid		// Error 32-bit EL1
-END(hibernate_el2_vectors)
+SYM_CODE_END(hibernate_el2_vectors)
 
 .popsection
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index e473ead806ed..160f5881a0b7 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -21,7 +21,7 @@
 
 	.align 11
 
-ENTRY(__hyp_stub_vectors)
+SYM_CODE_START(__hyp_stub_vectors)
 	ventry	el2_sync_invalid		// Synchronous EL2t
 	ventry	el2_irq_invalid			// IRQ EL2t
 	ventry	el2_fiq_invalid			// FIQ EL2t
@@ -41,11 +41,11 @@ ENTRY(__hyp_stub_vectors)
 	ventry	el1_irq_invalid			// IRQ 32-bit EL1
 	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
 	ventry	el1_error_invalid		// Error 32-bit EL1
-ENDPROC(__hyp_stub_vectors)
+SYM_CODE_END(__hyp_stub_vectors)
 
 	.align 11
 
-el1_sync:
+SYM_CODE_START_LOCAL(el1_sync)
 	cmp	x0, #HVC_SET_VECTORS
 	b.ne	2f
 	msr	vbar_el2, x1
@@ -68,12 +68,12 @@ el1_sync:
 
 9:	mov	x0, xzr
 	eret
-ENDPROC(el1_sync)
+SYM_CODE_END(el1_sync)
 
 .macro invalid_vector	label
-\label:
+SYM_CODE_START_LOCAL(\label)
 	b \label
-ENDPROC(\label)
+SYM_CODE_END(\label)
 .endm
 
 	invalid_vector	el2_sync_invalid
@@ -106,15 +106,15 @@ ENDPROC(\label)
  * initialisation entry point.
  */
 
-ENTRY(__hyp_set_vectors)
+SYM_FUNC_START(__hyp_set_vectors)
 	mov	x1, x0
 	mov	x0, #HVC_SET_VECTORS
 	hvc	#0
 	ret
-ENDPROC(__hyp_set_vectors)
+SYM_FUNC_END(__hyp_set_vectors)
 
-ENTRY(__hyp_reset_vectors)
+SYM_FUNC_START(__hyp_reset_vectors)
 	mov	x0, #HVC_RESET_VECTORS
 	hvc	#0
 	ret
-ENDPROC(__hyp_reset_vectors)
+SYM_FUNC_END(__hyp_reset_vectors)
diff --git a/arch/arm64/kernel/probes/kprobes_trampoline.S b/arch/arm64/kernel/probes/kprobes_trampoline.S
index 45dce03aaeaf..890ca72c5a51 100644
--- a/arch/arm64/kernel/probes/kprobes_trampoline.S
+++ b/arch/arm64/kernel/probes/kprobes_trampoline.S
@@ -61,7 +61,7 @@
 	ldp x28, x29, [sp, #S_X28]
 	.endm
 
-ENTRY(kretprobe_trampoline)
+SYM_CODE_START(kretprobe_trampoline)
 	sub sp, sp, #S_FRAME_SIZE
 
 	save_all_base_regs
@@ -79,4 +79,4 @@ ENTRY(kretprobe_trampoline)
 	add sp, sp, #S_FRAME_SIZE
 	ret
 
-ENDPROC(kretprobe_trampoline)
+SYM_CODE_END(kretprobe_trampoline)
diff --git a/arch/arm64/kernel/reloc_test_syms.S b/arch/arm64/kernel/reloc_test_syms.S
index 16a34f188f26..53e8cdfe80e1 100644
--- a/arch/arm64/kernel/reloc_test_syms.S
+++ b/arch/arm64/kernel/reloc_test_syms.S
@@ -5,81 +5,81 @@
 
 #include <linux/linkage.h>
 
-ENTRY(absolute_data64)
+SYM_CODE_START(absolute_data64)
 	ldr	x0, 0f
 	ret
 0:	.quad	sym64_abs
-ENDPROC(absolute_data64)
+SYM_CODE_END(absolute_data64)
 
-ENTRY(absolute_data32)
+SYM_CODE_START(absolute_data32)
 	ldr	w0, 0f
 	ret
 0:	.long	sym32_abs
-ENDPROC(absolute_data32)
+SYM_CODE_END(absolute_data32)
 
-ENTRY(absolute_data16)
+SYM_CODE_START(absolute_data16)
 	adr	x0, 0f
 	ldrh	w0, [x0]
 	ret
 0:	.short	sym16_abs, 0
-ENDPROC(absolute_data16)
+SYM_CODE_END(absolute_data16)
 
-ENTRY(signed_movw)
+SYM_CODE_START(signed_movw)
 	movz	x0, #:abs_g2_s:sym64_abs
 	movk	x0, #:abs_g1_nc:sym64_abs
 	movk	x0, #:abs_g0_nc:sym64_abs
 	ret
-ENDPROC(signed_movw)
+SYM_CODE_END(signed_movw)
 
-ENTRY(unsigned_movw)
+SYM_CODE_START(unsigned_movw)
 	movz	x0, #:abs_g3:sym64_abs
 	movk	x0, #:abs_g2_nc:sym64_abs
 	movk	x0, #:abs_g1_nc:sym64_abs
 	movk	x0, #:abs_g0_nc:sym64_abs
 	ret
-ENDPROC(unsigned_movw)
+SYM_CODE_END(unsigned_movw)
 
 	.align	12
 	.space	0xff8
-ENTRY(relative_adrp)
+SYM_CODE_START(relative_adrp)
 	adrp	x0, sym64_rel
 	add	x0, x0, #:lo12:sym64_rel
 	ret
-ENDPROC(relative_adrp)
+SYM_CODE_END(relative_adrp)
 
 	.align	12
 	.space	0xffc
-ENTRY(relative_adrp_far)
+SYM_CODE_START(relative_adrp_far)
 	adrp	x0, memstart_addr
 	add	x0, x0, #:lo12:memstart_addr
 	ret
-ENDPROC(relative_adrp_far)
+SYM_CODE_END(relative_adrp_far)
 
-ENTRY(relative_adr)
+SYM_CODE_START(relative_adr)
 	adr	x0, sym64_rel
 	ret
-ENDPROC(relative_adr)
+SYM_CODE_END(relative_adr)
 
-ENTRY(relative_data64)
+SYM_CODE_START(relative_data64)
 	adr	x1, 0f
 	ldr	x0, [x1]
 	add	x0, x0, x1
 	ret
 0:	.quad	sym64_rel - .
-ENDPROC(relative_data64)
+SYM_CODE_END(relative_data64)
 
-ENTRY(relative_data32)
+SYM_CODE_START(relative_data32)
 	adr	x1, 0f
 	ldr	w0, [x1]
 	add	x0, x0, x1
 	ret
 0:	.long	sym64_rel - .
-ENDPROC(relative_data32)
+SYM_CODE_END(relative_data32)
 
-ENTRY(relative_data16)
+SYM_CODE_START(relative_data16)
 	adr	x1, 0f
 	ldrsh	w0, [x1]
 	add	x0, x0, x1
 	ret
 0:	.short	sym64_rel - ., 0
-ENDPROC(relative_data16)
+SYM_CODE_END(relative_data16)
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index c40ce496c78b..542d6edc6806 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -26,7 +26,7 @@
  * control_code_page, a special page which has been set up to be preserved
  * during the copy operation.
  */
-ENTRY(arm64_relocate_new_kernel)
+SYM_CODE_START(arm64_relocate_new_kernel)
 
 	/* Setup the list loop variables. */
 	mov	x18, x2				/* x18 = dtb address */
@@ -111,7 +111,7 @@ ENTRY(arm64_relocate_new_kernel)
 	mov	x3, xzr
 	br	x17
 
-ENDPROC(arm64_relocate_new_kernel)
+SYM_CODE_END(arm64_relocate_new_kernel)
 
 .align 3	/* To keep the 64-bit values below naturally aligned. */
 
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index 7b2f2e650c44..70e5e697ebc7 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -62,7 +62,7 @@
  *
  *  x0 = struct sleep_stack_data area
  */
-ENTRY(__cpu_suspend_enter)
+SYM_FUNC_START(__cpu_suspend_enter)
 	stp	x29, lr, [x0, #SLEEP_STACK_DATA_CALLEE_REGS]
 	stp	x19, x20, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+16]
 	stp	x21, x22, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+32]
@@ -95,10 +95,10 @@ ENTRY(__cpu_suspend_enter)
 	ldp	x29, lr, [sp], #16
 	mov	x0, #1
 	ret
-ENDPROC(__cpu_suspend_enter)
+SYM_FUNC_END(__cpu_suspend_enter)
 
 	.pushsection ".idmap.text", "awx"
-ENTRY(cpu_resume)
+SYM_FUNC_START(cpu_resume)
 	bl	el2_setup		// if in EL2 drop to EL1 cleanly
 	mov	x0, #ARM64_CPU_RUNTIME
 	bl	__cpu_setup
@@ -107,11 +107,11 @@ ENTRY(cpu_resume)
 	bl	__enable_mmu
 	ldr	x8, =_cpu_resume
 	br	x8
-ENDPROC(cpu_resume)
+SYM_FUNC_END(cpu_resume)
 	.ltorg
 	.popsection
 
-ENTRY(_cpu_resume)
+SYM_FUNC_START(_cpu_resume)
 	mrs	x1, mpidr_el1
 	adr_l	x8, mpidr_hash		// x8 = struct mpidr_hash virt address
 
@@ -147,4 +147,4 @@ ENTRY(_cpu_resume)
 	ldp	x29, lr, [x29]
 	mov	x0, #0
 	ret
-ENDPROC(_cpu_resume)
+SYM_FUNC_END(_cpu_resume)
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 54655273d1e0..1f93809528a4 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -30,9 +30,9 @@
  *		  unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
  *		  struct arm_smccc_quirk *quirk)
  */
-ENTRY(__arm_smccc_smc)
+SYM_FUNC_START(__arm_smccc_smc)
 	SMCCC	smc
-ENDPROC(__arm_smccc_smc)
+SYM_FUNC_END(__arm_smccc_smc)
 EXPORT_SYMBOL(__arm_smccc_smc)
 
 /*
@@ -41,7 +41,7 @@ EXPORT_SYMBOL(__arm_smccc_smc)
  *		  unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
  *		  struct arm_smccc_quirk *quirk)
  */
-ENTRY(__arm_smccc_hvc)
+SYM_FUNC_START(__arm_smccc_hvc)
 	SMCCC	hvc
-ENDPROC(__arm_smccc_hvc)
+SYM_FUNC_END(__arm_smccc_hvc)
 EXPORT_SYMBOL(__arm_smccc_hvc)
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 02/10] arm64: bti: Support building kernel C code using BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
  2020-04-15 13:07 ` [PATCH 01/10] arm64: kernel: Convert to modern annotations for assembly functions Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 03/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI Mark Brown
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

When running with BTI enabled we need to ask the compiler to enable
generation of BTI landing pads beyond those generated as a result of
pointer authentication instructions being landing pads. Since the two
features are practically speaking unlikely to be used separately we
will make kernel mode BTI depend on pointer authentication in order
to simplify the Makefile.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 85e4149cc5d5..90150b5b180e 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -71,7 +71,11 @@ branch-prot-flags-y += $(call cc-option,-mbranch-protection=none)
 
 ifeq ($(CONFIG_ARM64_PTR_AUTH),y)
 branch-prot-flags-$(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS) := -msign-return-address=all
+ifeq ($(CONFIG_ARM64_BTI_KERNEL),y)
+branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI) := -mbranch-protection=pac-ret+leaf+bti
+else
 branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf
+endif
 # -march=armv8.3-a enables the non-nops instructions for PAC, to avoid the
 # compiler to generate them and consequently to break the single image contract
 # we pass it only to the assembler. This option is utilized only in case of non
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 03/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
  2020-04-15 13:07 ` [PATCH 01/10] arm64: kernel: Convert to modern annotations for assembly functions Mark Brown
  2020-04-15 13:07 ` [PATCH 02/10] arm64: bti: Support building kernel C code using BTI Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel Mark Brown
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

When the kernel is built for BTI override SYM_FUNC_START and related macros
to add a BTI landing pad to the start of all global functions, ensuring that
they are BTI safe. The ; at the end of the BTI_C macro is for the benefit of
the macro-generated functions in xen-hypercall.S.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/linkage.h | 46 ++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
index ebee3113a62f..d8d5b0f77216 100644
--- a/arch/arm64/include/asm/linkage.h
+++ b/arch/arm64/include/asm/linkage.h
@@ -4,6 +4,52 @@
 #define __ALIGN		.align 2
 #define __ALIGN_STR	".align 2"
 
+#ifdef CONFIG_ARM64_BTI_KERNEL
+
+/*
+ * Since current versions of gas reject the BTI instruction unless we
+ * set the architecture version to v8.5 we use the hint instruction
+ * instead.
+ */
+#define BTI_C hint 34 ;
+#define BTI_J hint 36 ;
+
+/*
+ * When using in-kernel BTI we need to ensure that assembly functions
+ * have suitable annotations.  Override SYM_FUNC_START to insert a BTI
+ * landing pad at the start of everything.
+ */
+#define SYM_FUNC_START(name)				\
+	SYM_START(name, SYM_L_GLOBAL, SYM_A_ALIGN)	\
+	BTI_C
+
+#define SYM_FUNC_START_NOALIGN(name)			\
+	SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE)	\
+	BTI_C
+
+#define SYM_FUNC_START_LOCAL(name)			\
+	SYM_START(name, SYM_L_LOCAL, SYM_A_ALIGN)	\
+	BTI_C
+
+#define SYM_FUNC_START_LOCAL_NOALIGN(name)		\
+	SYM_START(name, SYM_L_LOCAL, SYM_A_NONE)	\
+	BTI_C
+
+#define SYM_FUNC_START_WEAK(name)			\
+	SYM_START(name, SYM_L_WEAK, SYM_A_ALIGN)	\
+	BTI_C
+
+#define SYM_FUNC_START_WEAK_NOALIGN(name)		\
+	SYM_START(name, SYM_L_WEAK, SYM_A_NONE)		\
+	BTI_C
+
+#define SYM_INNER_LABEL(name, linkage)			\
+	.type name SYM_T_NONE ASM_NL			\
+	SYM_ENTRY(name, linkage, SYM_A_NONE)		\
+	BTI_J
+
+#endif
+
 /*
  * Annotate a function as position independent, i.e., safe to be called before
  * the kernel virtual mapping is activated.
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (2 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 03/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-28 17:24   ` Catalin Marinas
  2020-04-15 13:07 ` [PATCH 05/10] arm64: mm: Mark module text as guarded pages Mark Brown
                   ` (6 subsequent siblings)
  10 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

Now that the kernel is built with BTI annotations enable the feature by
setting the GP bit in the stage 1 translation tables.  This is done
based on the features supported by the boot CPU so that we do not need
to rewrite the translation tables.

In order to avoid potential issues on big.LITTLE systems when there are
a mix of BTI and non-BTI capable CPUs in the system when we have enabled
kernel mode BTI we change BTI to be a _STRICT_BOOT_CPU_FEATURE when we
have kernel BTI.  This will prevent any CPUs that don't support BTI
being started if the boot CPU supports BTI rather than simply not using
BTI as we do when supporting BTI only in userspace.  The main concern is
the possibility of BTYPE being preserved by a CPU that does not
implement BTI when a thread is migrated to it resulting in an incorrect
state which could generate an exception when the thread migrates back to
a CPU that does support BTI.  If we encounter practical systems which
mix BTI and non-BTI CPUs we will need to revisit this implementation.

Since we currently do not generate landing pads in the BPF JIT we only
map the base kernel text in this way.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/pgtable-prot.h |  5 +++++
 arch/arm64/kernel/cpufeature.c        |  4 ++++
 arch/arm64/mm/mmu.c                   | 24 ++++++++++++++++++++++++
 3 files changed, 33 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 1305e28225fc..7213117ff538 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -21,6 +21,7 @@
 
 #ifndef __ASSEMBLY__
 
+#include <asm/cpufeature.h>
 #include <asm/pgtable-types.h>
 
 extern bool arm64_use_ng_mappings;
@@ -31,6 +32,8 @@ extern bool arm64_use_ng_mappings;
 #define PTE_MAYBE_NG		(arm64_use_ng_mappings ? PTE_NG : 0)
 #define PMD_MAYBE_NG		(arm64_use_ng_mappings ? PMD_SECT_NG : 0)
 
+#define PTE_MAYBE_GP		(system_supports_bti() ? PTE_GP : 0)
+
 #define PROT_DEFAULT		(_PROT_DEFAULT | PTE_MAYBE_NG)
 #define PROT_SECT_DEFAULT	(_PROT_SECT_DEFAULT | PMD_MAYBE_NG)
 
@@ -50,7 +53,9 @@ extern bool arm64_use_ng_mappings;
 #define PAGE_KERNEL		__pgprot(PROT_NORMAL)
 #define PAGE_KERNEL_RO		__pgprot((PROT_NORMAL & ~PTE_WRITE) | PTE_RDONLY)
 #define PAGE_KERNEL_ROX		__pgprot((PROT_NORMAL & ~(PTE_WRITE | PTE_PXN)) | PTE_RDONLY)
+#define PAGE_KERNEL_ROX_GP	__pgprot((PROT_NORMAL & ~(PTE_WRITE | PTE_PXN)) | PTE_RDONLY | PTE_GP)
 #define PAGE_KERNEL_EXEC	__pgprot(PROT_NORMAL & ~PTE_PXN)
+#define PAGE_KERNEL_EXEC_GP	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_GP)
 #define PAGE_KERNEL_EXEC_CONT	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT)
 
 #define PAGE_HYP		__pgprot(_HYP_PAGE_DEFAULT | PTE_HYP | PTE_HYP_XN)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9793d3aa9d98..84fea674856f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1800,7 +1800,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 	{
 		.desc = "Branch Target Identification",
 		.capability = ARM64_BTI,
+#ifdef CONFIG_ARM64_BTI_KERNEL
+		.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
+#else
 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+#endif
 		.matches = has_cpuid_feature,
 		.cpu_enable = bti_enable,
 		.sys_reg = SYS_ID_AA64PFR1_EL1,
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a374e4f51a62..c299b73dd5e4 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -609,6 +609,22 @@ static int __init map_entry_trampoline(void)
 core_initcall(map_entry_trampoline);
 #endif
 
+/*
+ * Open coded check for BTI, only for use to determine configuration
+ * for early mappings for before the cpufeature code has run.
+ */
+static bool arm64_early_this_cpu_has_bti(void)
+{
+	u64 pfr1;
+
+	if (!IS_ENABLED(CONFIG_ARM64_BTI_KERNEL))
+		return false;
+
+	pfr1 = read_sysreg_s(SYS_ID_AA64PFR1_EL1);
+	return cpuid_feature_extract_unsigned_field(pfr1,
+						    ID_AA64PFR1_BT_SHIFT);
+}
+
 /*
  * Create fine-grained mappings for the kernel.
  */
@@ -624,6 +640,14 @@ static void __init map_kernel(pgd_t *pgdp)
 	 */
 	pgprot_t text_prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
 
+	/*
+	 * If we have a CPU that supports BTI and a kernel built for
+	 * BTI then mark the kernel executable text as guarded pages
+	 * now so we don't have to rewrite the page tables later.
+	 */
+	if (arm64_early_this_cpu_has_bti())
+		text_prot = __pgprot_modify(text_prot, PTE_GP, PTE_GP);
+
 	/*
 	 * Only rodata will be remapped with different permissions later on,
 	 * all other segments are allowed to use contiguous mappings.
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 05/10] arm64: mm: Mark module text as guarded pages
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (3 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-27 15:07   ` Mark Brown
  2020-04-15 13:07 ` [PATCH 06/10] arm64: bti: Provide Kconfig for kernel mode BTI Mark Brown
                   ` (5 subsequent siblings)
  10 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

When the kernel is built for BTI and running on a system which supports
it extend guard page coverage to include executable code from loadable
modules.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/mm/pageattr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 250c49008d73..bde08090b838 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -126,13 +126,13 @@ int set_memory_nx(unsigned long addr, int numpages)
 {
 	return change_memory_common(addr, numpages,
 					__pgprot(PTE_PXN),
-					__pgprot(0));
+					__pgprot(PTE_MAYBE_GP));
 }
 
 int set_memory_x(unsigned long addr, int numpages)
 {
 	return change_memory_common(addr, numpages,
-					__pgprot(0),
+					__pgprot(PTE_MAYBE_GP),
 					__pgprot(PTE_PXN));
 }
 
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 06/10] arm64: bti: Provide Kconfig for kernel mode BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (4 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 05/10] arm64: mm: Mark module text as guarded pages Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI Mark Brown
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

Now that all the code is in place provide a Kconfig option allowing users
to enable BTI for the kernel if their toolchain supports it, defaulting it
on since this has security benefits. This is a separate configuration
option since we currently don't support secondary CPUs that lack BTI if
the boot CPU supports it.

Current testing appears to show an issue with GCC which causes it to
emit unsuitable landing pads for function entries in some cases, until
this issue is understood and either our usage fixed or a suitable
version of GCC is identified the feature is marked as incompatible with
GCC.  No issues have been identified with clang.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/Kconfig | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43be825d0730..ceccafeb3cd7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1609,6 +1609,24 @@ config ARM64_BTI
 	  BTI, such binaries can still run, but you get no additional
 	  enforcement of branch destinations.
 
+config ARM64_BTI_KERNEL
+	bool "Use Branch Target Identification for kernel"
+	default y
+	depends on ARM64_BTI
+	depends on ARM64_PTR_AUTH
+	depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI
+	depends on !CC_IS_GCC
+	depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
+	help
+	  Build the kernel with Branch Target Identification annotations
+	  and enable enforcement of this for kernel code. When this option
+	  is enabled and the system supports BTI all kernel code including
+	  modular code must have BTI enabled.
+
+config CC_HAS_BRANCH_PROT_PAC_RET_BTI
+	# GCC 9 or later, clang 8 or later
+	def_bool $(cc-option,-mbranch-protection=pac-ret+leaf+bti)
+
 config ARM64_E0PD
 	bool "Enable support for E0PD"
 	default y
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (5 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 06/10] arm64: bti: Provide Kconfig for kernel mode BTI Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 08/10] arm64: vdso: Annotate " Mark Brown
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

ELF files built for BTI should have a program property note section which
identifies them as such. The linker expects to find this note in all
object files it is linking into a BTI annotated output, the compiler will
ensure that this happens for C files but for assembler files we need to do
this in the source so provide a macro which can be used for this purpose.

This is mainly for use in the VDSO which should be a normal ELF shared
library and should therefore include BTI annotations when built for BTI.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/assembler.h | 41 ++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 0bff325117b4..85a88df2d0fe 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -736,4 +736,45 @@ USER(\label, ic	ivau, \tmp2)			// invalidate I line PoU
 .Lyield_out_\@ :
 	.endm
 
+/*
+ * This macro emits a program property note section identifying
+ * architecture features which require special handling, mainly for
+ * use in assembly files included in the VDSO.
+ */
+
+#ifdef CONFIG_ARM64_BTI_KERNEL
+
+#define NT_GNU_PROPERTY_TYPE_0  5
+#define GNU_PROPERTY_AARCH64_FEATURE_1_AND      0xc0000000
+
+#define GNU_PROPERTY_AARCH64_FEATURE_1_BTI      (1U << 0)
+#define GNU_PROPERTY_AARCH64_FEATURE_1_PAC      (1U << 1)
+
+.macro emit_aarch64_feature_1_and
+	.pushsection .note.gnu.property, "a"
+	.align  3
+	.long   2f - 1f
+	.long   6f - 3f
+	.long   NT_GNU_PROPERTY_TYPE_0
+1:      .string "GNU"
+2:
+	.align  3
+3:      .long   GNU_PROPERTY_AARCH64_FEATURE_1_AND
+	.long   5f - 4f
+4:
+	.long   GNU_PROPERTY_AARCH64_FEATURE_1_PAC | \
+		GNU_PROPERTY_AARCH64_FEATURE_1_BTI
+5:
+	.align  3
+6:
+	.popsection
+.endm
+
+#else
+
+.macro emit_aarch64_feature_1_and
+.endm
+
+#endif  /* CONFIG_ARM64_BTI_KERNEL */
+
 #endif	/* __ASM_ASSEMBLER_H */
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 08/10] arm64: vdso: Annotate for BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (6 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 09/10] arm64: vdso: Force the vDSO to be linked as BTI when built " Mark Brown
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

Generate BTI annotations for all assembly files included in the 64 bit
vDSO.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/vdso/note.S      | 3 +++
 arch/arm64/kernel/vdso/sigreturn.S | 3 +++
 arch/arm64/kernel/vdso/vdso.S      | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/arch/arm64/kernel/vdso/note.S b/arch/arm64/kernel/vdso/note.S
index 0ce6ec75a525..3d4e82290c80 100644
--- a/arch/arm64/kernel/vdso/note.S
+++ b/arch/arm64/kernel/vdso/note.S
@@ -12,9 +12,12 @@
 #include <linux/version.h>
 #include <linux/elfnote.h>
 #include <linux/build-salt.h>
+#include <asm/assembler.h>
 
 ELFNOTE_START(Linux, 0, "a")
 	.long LINUX_VERSION_CODE
 ELFNOTE_END
 
 BUILD_SALT
+
+emit_aarch64_feature_1_and
diff --git a/arch/arm64/kernel/vdso/sigreturn.S b/arch/arm64/kernel/vdso/sigreturn.S
index 12324863d5c2..3fb13b81f780 100644
--- a/arch/arm64/kernel/vdso/sigreturn.S
+++ b/arch/arm64/kernel/vdso/sigreturn.S
@@ -9,6 +9,7 @@
  */
 
 #include <linux/linkage.h>
+#include <asm/assembler.h>
 #include <asm/unistd.h>
 
 	.text
@@ -24,3 +25,5 @@ SYM_FUNC_START(__kernel_rt_sigreturn)
 	svc	#0
 	.cfi_endproc
 SYM_FUNC_END(__kernel_rt_sigreturn)
+
+emit_aarch64_feature_1_and
diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S
index d1414fee5274..c4b1990bf2be 100644
--- a/arch/arm64/kernel/vdso/vdso.S
+++ b/arch/arm64/kernel/vdso/vdso.S
@@ -8,6 +8,7 @@
 #include <linux/init.h>
 #include <linux/linkage.h>
 #include <linux/const.h>
+#include <asm/assembler.h>
 #include <asm/page.h>
 
 	.globl vdso_start, vdso_end
@@ -19,3 +20,5 @@ vdso_start:
 vdso_end:
 
 	.previous
+
+emit_aarch64_feature_1_and
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 09/10] arm64: vdso: Force the vDSO to be linked as BTI when built for BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (7 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 08/10] arm64: vdso: Annotate " Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 10/10] arm64: vdso: Map the vDSO text with guarded pages " Mark Brown
  2020-04-15 13:07 ` [PATCH 10/10] arm64: vdso: Map the VDSO " Mark Brown
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

When the kernel and hence vDSO are built with BTI enabled force the linker
to link the vDSO as BTI. This will cause the linker to warn if any of the
input files do not have the BTI annotation, ensuring that we don't silently
fail to provide a vDSO that is not built and annotated for BTI when the
kernel is being built with BTI.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/vdso/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index dd2514bb1511..51ad1cce8133 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -17,8 +17,10 @@ obj-vdso := vgettimeofday.o note.o sigreturn.o
 targets := $(obj-vdso) vdso.so vdso.so.dbg
 obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
 
+btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
+
 ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
-		--build-id -n -T
+		--build-id -n $(btildflags-y) -T
 
 ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18
 ccflags-y += -DDISABLE_BRANCH_PROFILING
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 10/10] arm64: vdso: Map the vDSO text with guarded pages when built for BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (8 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 09/10] arm64: vdso: Force the vDSO to be linked as BTI when built " Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  2020-04-15 13:07 ` [PATCH 10/10] arm64: vdso: Map the VDSO " Mark Brown
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

The kernel is responsible for mapping the vDSO into userspace processes,
including mapping the text section as executable. Handle the mapping of
the vDSO for BTI similarly, mapping the text section as guarded pages so
the BTI annotations in the vDSO become effective when they are present.

This will mean that we can have BTI active for the vDSO in processes that
do not otherwise support BTI. This should not be an issue for any expected
use of the vDSO.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/vdso.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 354b11e27c07..9271b7774df0 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -142,6 +142,7 @@ static int __setup_additional_pages(enum arch_vdso_type arch_index,
 				    int uses_interp)
 {
 	unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
+	unsigned long gp_flags = 0;
 	void *ret;
 
 	vdso_text_len = vdso_lookup[arch_index].vdso_pages << PAGE_SHIFT;
@@ -160,10 +161,13 @@ static int __setup_additional_pages(enum arch_vdso_type arch_index,
 	if (IS_ERR(ret))
 		goto up_fail;
 
+	if (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL) && system_supports_bti())
+		gp_flags = VM_ARM64_BTI;
+
 	vdso_base += PAGE_SIZE;
 	mm->context.vdso = (void *)vdso_base;
 	ret = _install_special_mapping(mm, vdso_base, vdso_text_len,
-				       VM_READ|VM_EXEC|
+				       VM_READ|VM_EXEC|gp_flags|
 				       VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				       vdso_lookup[arch_index].cm);
 	if (IS_ERR(ret))
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 10/10] arm64: vdso: Map the VDSO text with guarded pages when built for BTI
  2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
                   ` (9 preceding siblings ...)
  2020-04-15 13:07 ` [PATCH 10/10] arm64: vdso: Map the vDSO text with guarded pages " Mark Brown
@ 2020-04-15 13:07 ` Mark Brown
  10 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-15 13:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Mark Brown, Kees Cook, linux-arm-kernel

The kernel is responsible for mapping the VDSO into userspace processes,
including mapping the text section as executable. Handle the mapping of
the VDSO for BTI similarly, mapping the text section as guarded pages so
the BTI annotations in the VDSO become effective when they are present.

This will mean that we can have BTI active for the VDSO in processes that
do not otherwise support BTI. This should not be an issue for any expected
use of the VDSO.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/vdso.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 354b11e27c07..9271b7774df0 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -142,6 +142,7 @@ static int __setup_additional_pages(enum arch_vdso_type arch_index,
 				    int uses_interp)
 {
 	unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
+	unsigned long gp_flags = 0;
 	void *ret;
 
 	vdso_text_len = vdso_lookup[arch_index].vdso_pages << PAGE_SHIFT;
@@ -160,10 +161,13 @@ static int __setup_additional_pages(enum arch_vdso_type arch_index,
 	if (IS_ERR(ret))
 		goto up_fail;
 
+	if (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL) && system_supports_bti())
+		gp_flags = VM_ARM64_BTI;
+
 	vdso_base += PAGE_SIZE;
 	mm->context.vdso = (void *)vdso_base;
 	ret = _install_special_mapping(mm, vdso_base, vdso_text_len,
-				       VM_READ|VM_EXEC|
+				       VM_READ|VM_EXEC|gp_flags|
 				       VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				       vdso_lookup[arch_index].cm);
 	if (IS_ERR(ret))
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 05/10] arm64: mm: Mark module text as guarded pages
  2020-04-15 13:07 ` [PATCH 05/10] arm64: mm: Mark module text as guarded pages Mark Brown
@ 2020-04-27 15:07   ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-27 15:07 UTC (permalink / raw)
  To: Vincenzo Frascino, Will Deacon, Catalin Marinas
  Cc: Kees Cook, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]

On Wed, Apr 15, 2020 at 02:07:44PM +0100, Mark Brown wrote:
> When the kernel is built for BTI and running on a system which supports
> it extend guard page coverage to include executable code from loadable
> modules.

It turns out on deeper testing that this doesn't work with BPF so this
patch shouldn't be applied just now, the rest of the series isn't
impacted.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  2020-04-15 13:07 ` [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel Mark Brown
@ 2020-04-28 17:24   ` Catalin Marinas
  2020-04-28 18:03     ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2020-04-28 17:24 UTC (permalink / raw)
  To: Mark Brown; +Cc: Vincenzo Frascino, Will Deacon, Kees Cook, linux-arm-kernel

On Wed, Apr 15, 2020 at 02:07:43PM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 1305e28225fc..7213117ff538 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -50,7 +53,9 @@ extern bool arm64_use_ng_mappings;
>  #define PAGE_KERNEL		__pgprot(PROT_NORMAL)
>  #define PAGE_KERNEL_RO		__pgprot((PROT_NORMAL & ~PTE_WRITE) | PTE_RDONLY)
>  #define PAGE_KERNEL_ROX		__pgprot((PROT_NORMAL & ~(PTE_WRITE | PTE_PXN)) | PTE_RDONLY)
> +#define PAGE_KERNEL_ROX_GP	__pgprot((PROT_NORMAL & ~(PTE_WRITE | PTE_PXN)) | PTE_RDONLY | PTE_GP)
>  #define PAGE_KERNEL_EXEC	__pgprot(PROT_NORMAL & ~PTE_PXN)
> +#define PAGE_KERNEL_EXEC_GP	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_GP)
>  #define PAGE_KERNEL_EXEC_CONT	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT)

Are the PAGE_*_GP defines used anywhere in this series?

> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9793d3aa9d98..84fea674856f 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1800,7 +1800,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  	{
>  		.desc = "Branch Target Identification",
>  		.capability = ARM64_BTI,
> +#ifdef CONFIG_ARM64_BTI_KERNEL
> +		.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
> +#else
>  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> +#endif

As with PtrAuth, I'm tempted to have a single config for both user and
kernel. Not a strong opinion though, just looking for some consistency.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  2020-04-28 17:24   ` Catalin Marinas
@ 2020-04-28 18:03     ` Mark Brown
  2020-04-29  7:40       ` Will Deacon
  0 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2020-04-28 18:03 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Vincenzo Frascino, Will Deacon, Kees Cook, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1202 bytes --]

On Tue, Apr 28, 2020 at 06:24:32PM +0100, Catalin Marinas wrote:
> On Wed, Apr 15, 2020 at 02:07:43PM +0100, Mark Brown wrote:

> > +#define PAGE_KERNEL_EXEC_GP	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_GP)
> >  #define PAGE_KERNEL_EXEC_CONT	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT)

> Are the PAGE_*_GP defines used anywhere in this series?

Not any more, I'll drop them.

> > +#ifdef CONFIG_ARM64_BTI_KERNEL
> > +		.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
> > +#else
> >  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > +#endif

> As with PtrAuth, I'm tempted to have a single config for both user and
> kernel. Not a strong opinion though, just looking for some consistency.

Yeah, it's not ideal.  My concern with this was that at the time I sent
the patches out GCC had a sufficiently severe code generation issue that
it was unsustainable to use for building the kernel.  That seemed
excessively restrictive so I made it a separate option.  This will be
fixed in GCC 10 all being well (one of the things I need to do before
reposting this is to verify that the current fix addresses everything I
was seeing and update the dependencies) so it's less of a concern
although still a bit annoying.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  2020-04-28 18:03     ` Mark Brown
@ 2020-04-29  7:40       ` Will Deacon
  2020-04-29 10:10         ` Mark Brown
  0 siblings, 1 reply; 17+ messages in thread
From: Will Deacon @ 2020-04-29  7:40 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Vincenzo Frascino, Kees Cook, linux-arm-kernel

On Tue, Apr 28, 2020 at 07:03:53PM +0100, Mark Brown wrote:
> On Tue, Apr 28, 2020 at 06:24:32PM +0100, Catalin Marinas wrote:
> > On Wed, Apr 15, 2020 at 02:07:43PM +0100, Mark Brown wrote:
> 
> > > +#define PAGE_KERNEL_EXEC_GP	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_GP)
> > >  #define PAGE_KERNEL_EXEC_CONT	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT)
> 
> > Are the PAGE_*_GP defines used anywhere in this series?
> 
> Not any more, I'll drop them.
> 
> > > +#ifdef CONFIG_ARM64_BTI_KERNEL
> > > +		.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
> > > +#else
> > >  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > > +#endif
> 
> > As with PtrAuth, I'm tempted to have a single config for both user and
> > kernel. Not a strong opinion though, just looking for some consistency.
> 
> Yeah, it's not ideal.  My concern with this was that at the time I sent
> the patches out GCC had a sufficiently severe code generation issue that
> it was unsustainable to use for building the kernel.  That seemed
> excessively restrictive so I made it a separate option.  This will be
> fixed in GCC 10 all being well (one of the things I need to do before
> reposting this is to verify that the current fix addresses everything I
> was seeing and update the dependencies) so it's less of a concern
> although still a bit annoying.

FWIW, I don't agree with Catalin here (I realise this is unhelpful ;) and
would much prefer to have separate config options for user and kernel. I
also think it would be worth doing this for pointer auth too, since at the
moment we have nonsensical dependencies such as user pointer auth depending
on VHE if KVM is enabled.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  2020-04-29  7:40       ` Will Deacon
@ 2020-04-29 10:10         ` Mark Brown
  0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2020-04-29 10:10 UTC (permalink / raw)
  To: Will Deacon
  Cc: Catalin Marinas, Vincenzo Frascino, Kees Cook, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 587 bytes --]

On Wed, Apr 29, 2020 at 08:40:15AM +0100, Will Deacon wrote:

> FWIW, I don't agree with Catalin here (I realise this is unhelpful ;) and
> would much prefer to have separate config options for user and kernel. I
> also think it would be worth doing this for pointer auth too, since at the
> moment we have nonsensical dependencies such as user pointer auth depending
> on VHE if KVM is enabled.

OK, I think the best thing for me to do for the time being is leave the
separate config option until you two sort things out one way or the
other, it's easier to merge them than split them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2020-04-29 10:10 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-15 13:07 [PATCH 00/10] arm64: BTI kernel and vDSO support Mark Brown
2020-04-15 13:07 ` [PATCH 01/10] arm64: kernel: Convert to modern annotations for assembly functions Mark Brown
2020-04-15 13:07 ` [PATCH 02/10] arm64: bti: Support building kernel C code using BTI Mark Brown
2020-04-15 13:07 ` [PATCH 03/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI Mark Brown
2020-04-15 13:07 ` [PATCH 04/10] arm64: Set GP bit in kernel page tables to enable BTI for the kernel Mark Brown
2020-04-28 17:24   ` Catalin Marinas
2020-04-28 18:03     ` Mark Brown
2020-04-29  7:40       ` Will Deacon
2020-04-29 10:10         ` Mark Brown
2020-04-15 13:07 ` [PATCH 05/10] arm64: mm: Mark module text as guarded pages Mark Brown
2020-04-27 15:07   ` Mark Brown
2020-04-15 13:07 ` [PATCH 06/10] arm64: bti: Provide Kconfig for kernel mode BTI Mark Brown
2020-04-15 13:07 ` [PATCH 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI Mark Brown
2020-04-15 13:07 ` [PATCH 08/10] arm64: vdso: Annotate " Mark Brown
2020-04-15 13:07 ` [PATCH 09/10] arm64: vdso: Force the vDSO to be linked as BTI when built " Mark Brown
2020-04-15 13:07 ` [PATCH 10/10] arm64: vdso: Map the vDSO text with guarded pages " Mark Brown
2020-04-15 13:07 ` [PATCH 10/10] arm64: vdso: Map the VDSO " Mark Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.