Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 7 Apr 2023 00:24:25 -0700
From:   Josh Poimboeuf <jpoimboe@kernel.org>
To:     Kees Cook <keescook@chromium.org>
Cc:     Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org
Subject: lkdtm_UNSET_SMEP() with IBT
Message-ID: <20230407072425.zfsy272vk46agno4@treble>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Precedence: bulk

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