linux-kernel - [tip: x86/paravirt] x86/paravirt: Use %rip-relative addressing in hook calls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <164305241532.16921.6031632679880039280.tip-bot2@tip-bot2>
Date:   Mon, 24 Jan 2022 19:26:55 -0000
From:   "tip-bot2 for Jan Beulich" <tip-bot2@...utronix.de>
To:     linux-tip-commits@...r.kernel.org
Cc:     Jan Beulich <jbeulich@...e.com>, Borislav Petkov <bp@...e.de>,
        Juergen Gross <jgross@...e.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [tip: x86/paravirt] x86/paravirt: Use %rip-relative addressing in hook calls

The following commit has been merged into the x86/paravirt branch of tip:

Commit-ID:     2e1f8e55f9e054b4a49ffc06c7e33b5d4725f05e
Gitweb:        https://git.kernel.org/tip/2e1f8e55f9e054b4a49ffc06c7e33b5d4725f05e
Author:        Jan Beulich <jbeulich@...e.com>
AuthorDate:    Thu, 30 Sep 2021 14:40:38 +02:00
Committer:     Borislav Petkov <bp@...e.de>
CommitterDate: Mon, 24 Jan 2022 20:21:19 +01:00

x86/paravirt: Use %rip-relative addressing in hook calls

While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary:

  ff 14 25 98 89 42 82    call   *0xffffffff82428998

Instead of using an "i" constraint with address-of operator and a 'c'
operand modifier, simply use an ordinary "m" constraint, which the
64-bit compiler will translate to %rip-relative addressing:

  ff 15 62 fb d2 00       call   *0xd2fb62(%rip)	# ffffffff82428998 <pv_ops+0x18>

This way the compiler is also told the truth about operand usage - the
memory location gets actually read, after all.

32-bit code generation is unaffected by the change.

  [ bp: Remove "we", add examples. ]

Signed-off-by: Jan Beulich <jbeulich@...e.com>
Signed-off-by: Borislav Petkov <bp@...e.de>
Reviewed-by: Juergen Gross <jgross@...e.com>
Link: https://lore.kernel.org/r/b8192e8a-13ef-6ac6-6364-8ba58992cd1d@suse.com
---
 arch/x86/include/asm/paravirt_types.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index a69012e..e159146 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -279,7 +279,7 @@ extern void (*paravirt_iret)(void);
 
 #define paravirt_type(op)				\
 	[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),	\
-	[paravirt_opptr] "i" (&(pv_ops.op))
+	[paravirt_opptr] "m" (pv_ops.op)
 #define paravirt_clobber(clobber)		\
 	[paravirt_clobber] "i" (clobber)
 
@@ -316,7 +316,7 @@ int paravirt_disable_iospace(void);
  */
 #define PARAVIRT_CALL					\
 	ANNOTATE_RETPOLINE_SAFE				\
-	"call *%c[paravirt_opptr];"
+	"call *%[paravirt_opptr];"
 
 /*
  * These macros are intended to wrap calls through one of the paravirt