mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* lkdtm_UNSET_SMEP() with IBT
@ 2023-04-07  7:24 Josh Poimboeuf
  0 siblings, 0 replies; only message in thread
From: Josh Poimboeuf @ 2023-04-07  7:24 UTC (permalink / raw)
  To: Kees Cook; +Cc: Peter Zijlstra, linux-kernel

Hi Kees,

I'm seeing the following warning:

  vmlinux.o: warning: objtool: lkdtm_UNSET_SMEP+0xe1: relocation to !ENDBR: native_write_cr4+0x40

The warning seems legit, lkdtm_UNSET_SMEP() is calling to the middle of
native_write_c4() which isn't going to have an ENDBR64.

The 0x40 offset comes from the MOV_CR4_DEPTH bounds check in the for
loop.  The compiler optimized the integer comparison into a pointer
comparison.

Some possible fixes:

- Skip the pinning verification test if cpu_feature_enabled(X86_FEATURE_IBT).

  That prevents the actual IBT violation, but it still doesn't make
  objtool happy.  Maybe there's some way to restructure the code to keep
  the compiler from generating that relocation to the MOV_CR4_DEPTH
  offset.

  I suppose we could add a special case in objtool to silence this
  particular warning, though we try to avoid that type of thing.

- Build-disable the pinning test if CONFIG_X86_KERNEL_IBT.  This may
  be overly broad, CONFIG_X86_KERNEL_IBT is enabled by default but many
  CPUs don't support it.

- Prefix the CR4 write with an ENDBR64 in native_write_c4(), if
  CONFIG_X86_KERNEL_IBT && CONFIG_LKDTM.

Thoughts?

-- 
Josh

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-04-07  7:24 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-07  7:24 lkdtm_UNSET_SMEP() with IBT Josh Poimboeuf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®