Thread (60 messages) 60 messages, 6 authors, 2020-01-21

Re: [PATCH v3 15/16] arm64: compile the kernel with ptrauth return address signing

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2020-01-17 11:49:59

On Mon, Dec 16, 2019 at 02:17:17PM +0530, Amit Daniel Kachhap wrote:
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 06b5025..f0798b7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1466,6 +1466,7 @@ config ARM64_PTR_AUTH
 	bool "Enable support for pointer authentication"
 	default y
 	depends on !KVM || ARM64_VHE
+	depends on GCC_VERSION >= 70000 || CLANG_VERSION >= 80000
Please don't add checks on compiler versions. Use cc-option when you
need a certain option rather than guessing which compiler version
supports it. People may do backports of different features, so the
version is not relevant.
quoted hunk ↗ jump to hunk
 	help
 	  Pointer authentication (part of the ARMv8.3 Extensions) provides
 	  instructions for signing and authenticating pointers against secret
@@ -1473,11 +1474,17 @@ config ARM64_PTR_AUTH
 	  and other attacks.
 
 	  This option enables these instructions at EL0 (i.e. for userspace).
-
 	  Choosing this option will cause the kernel to initialise secret keys
 	  for each process at exec() time, with these keys being
 	  context-switched along with the process.
 
+	  If the compiler supports the -mbranch-protection or
+	  -msign-return-address flag (e.g. GCC 7 or later), then this option
+	  will also cause the kernel itself to be compiled with return address
+	  protection. In this case, and if the target hardware is known to
+	  support pointer authentication, then CONFIG_STACKPROTECTOR can be
+	  disabled with minimal loss of protection.
+
 	  The feature is detected at runtime. If the feature is not present in
 	  hardware it will not be advertised to userspace/KVM guest nor will it
 	  be enabled. However, KVM guest also require VHE mode and hence
@@ -1488,6 +1495,18 @@ config ARM64_PTR_AUTH
 	  have address auth and the late CPU has then system panic will occur.
 	  On such a system, this option should not be selected.
 
+config CC_HAS_BRANCH_PROT_PAC_RET
+	# GCC 9 or later, clang 8 or later
+	def_bool $(cc-option,-mbranch-protection=pac-ret+leaf)
+
+config CC_HAS_SIGN_RETURN_ADDRESS
+	# GCC 7, 8
+	def_bool $(cc-option,-msign-return-address=all)
+
+config AS_HAS_PAC
+	def_bool $(as-option,-Wa,-march=armv8.3-a)
+	depends on CC_IS_CLANG
First, as I commented on the previous patch, clang seems to ignore -Wa,
so you can write whatever you want after it and it seems to be always
true.

Second, if you need the assembler to support certain features, it needs
to be checked irrespective of whether the compiler is gcc or clang.
Binutils is a separate package.
quoted hunk ↗ jump to hunk
+
 endmenu
 
 config ARM64_SVE
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 1fbe24d..6a1da59 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -72,6 +72,17 @@ stack_protector_prepare: prepare0
 					include/generated/asm-offsets.h))
 endif
 
+ifeq ($(CONFIG_ARM64_PTR_AUTH),y)
+branch-prot-flags-$(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS) := -msign-return-address=all
+branch-prot-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf
+# -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 when clang is selected as a compiler. For the GNU toolchain
+# this option is not used.
+branch-prot-flags-$(CONFIG_AS_HAS_PAC) += -Wa,-march=armv8.3-a
+KBUILD_CFLAGS += $(branch-prot-flags-y)
+endif
So, does this actually work with clang?

Please check the clang issue in case I'm mistaken. Otherwise, you could
use as-instr as in this patch:

https://lore.kernel.org/linux-arm-kernel/20200115113008.3334-3-catalin.marinas@arm.com/ (local)

Also Will had a preference for warning during build if the user
requested a feature in .config (i.e. PAC) but the compiler/assembler
does not support it (that was for the LSE patch above). You could
attempt something similar with this patch.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help