From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8719CC76196 for ; Fri, 7 Apr 2023 07:24:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231481AbjDGHYj (ORCPT ); Fri, 7 Apr 2023 03:24:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230141AbjDGHYh (ORCPT ); Fri, 7 Apr 2023 03:24:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1A72AF03 for ; Fri, 7 Apr 2023 00:24:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AD778649FE for ; Fri, 7 Apr 2023 07:24:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF4CBC433D2; Fri, 7 Apr 2023 07:24:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680852267; bh=pkE0yg4NEsMuY424B1fUDMze2BcBYrIeATbsW/86JnA=; h=Date:From:To:Cc:Subject:From; b=LNd969JNzM5FebmOsH14UhkV6Hp5vlAM2+Ll8YCDKvW6AUpJJYYhI3e1XVN3O40WU RGDDgSmVPokcztw9uY/Xk/BuJOo/MlgCNeUdihHSK1cvYSNzSmg+DAaf6/xnzCPu+U 74cqx8RBL9PxWPEhLV8sat9ibwSKnALyEgBLh/Gu5xkaQDz18iEYc1ILEdoDrsQyio sumO5Hcvk48snpOHVoMu+koGejKj2zMdwEdVZYJM/MUoRAC1XToUkuYFhQdVplU/G0 9aHZKB1ZqTxOWnXaaU2eifHV3wjVAfAAk5adtcjUSm/klv5S+RCIcueMi388iokMm6 /0AJPEqGjb9kw== Date: Fri, 7 Apr 2023 00:24:25 -0700 From: Josh Poimboeuf To: Kees Cook Cc: Peter Zijlstra , 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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