[v2,1/3] arm64: insn: Don't assume unrecognized HINTs are NOPs

Commit Message

Mark Brown April 28, 2020, 5:24 p.m. UTC

Currently the kernel assumes that any HINT which it does not explicitly
recognise is a NOP.  This is not robust as new instructions may be added
which need special handling, including recent extensions like PAC, and
in any case software should only be using explicit NOP instructions for
deliberate NOPs.

This has the effect of rendering PAC and BTI instructions unprobeable
which means that probes can't be inserted on the first instruction of
functions built with those features.

Signed-off-by: Mark Brown <[e-mail]>
Acked-by: Catalin Marinas <[e-mail]>
---
 arch/arm64/kernel/insn.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

Comments

Will Deacon April 30, 2020, 4:08 p.m. UTC | #1

On Tue, Apr 28, 2020 at 06:24:31PM +0100, Mark Brown wrote:
> Currently the kernel assumes that any HINT which it does not explicitly
> recognise is a NOP.  This is not robust as new instructions may be added
> which need special handling, including recent extensions like PAC, and
> in any case software should only be using explicit NOP instructions for
> deliberate NOPs.

Hmm, I'm not sure that using PAC as the justification makes tonnes of sense
here, since you go ahead and whitelist the PAC hints in patch 3!

Will

Patch

diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 4a9e773a177f..535a3a7a053e 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -58,14 +58,10 @@  bool __kprobes aarch64_insn_is_nop(u32 insn)
 		return false;
 
 	switch (insn & 0xFE0) {
-	case AARCH64_INSN_HINT_YIELD:
-	case AARCH64_INSN_HINT_WFE:
-	case AARCH64_INSN_HINT_WFI:
-	case AARCH64_INSN_HINT_SEV:
-	case AARCH64_INSN_HINT_SEVL:
-		return false;
-	default:
+	case AARCH64_INSN_HINT_NOP:
 		return true;
+	default:
+		return false;
 	}
 }