From 4a03aa34432abe0703abf232f31fc5e2ed8256f6 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Mon, 14 Nov 2022 16:23:45 +0100 Subject: [PATCH] lkdtm: Avoid objtool/ibt warning For certain configs objtool will complain like: vmlinux.o: warning: objtool: lkdtm_UNSET_SMEP+0x1c3: relocation to !ENDBR: native_write_cr4+0x41 What happens is that GCC optimizes the loop: insn = (unsigned char *)native_write_cr4; for (i = 0; i < MOV_CR4_DEPTH; i++) to read something like: for (insn = (unsigned char *)native_write_cr4; insn < (unsigned char *)native_write_cr4 + MOV_CR4_DEPTH; insn++) Which then obviously generates the text reference native_write_cr4+041. Since none of this is a fast path, simply confuse GCC enough to inhibit this optimization. Reported-by: kernel test robot Signed-off-by: Peter Zijlstra (Intel) Acked-by: Kees Cook Link: https://lore.kernel.org/r/Y3JdgbXRV0MNZ+9h@hirez.programming.kicks-ass.net Signed-off-by: Josh Poimboeuf --- drivers/misc/lkdtm/bugs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c index 48821f4..92110cb 100644 --- a/drivers/misc/lkdtm/bugs.c +++ b/drivers/misc/lkdtm/bugs.c @@ -487,6 +487,7 @@ static void lkdtm_UNSET_SMEP(void) * the cr4 writing instruction. */ insn = (unsigned char *)native_write_cr4; + OPTIMIZER_HIDE_VAR(insn); for (i = 0; i < MOV_CR4_DEPTH; i++) { /* mov %rdi, %cr4 */ if (insn[i] == 0x0f && insn[i+1] == 0x22 && insn[i+2] == 0xe7) -- 2.7.4