[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGc5_AM2AkE+h8EcvYjAGHqeDWRyVRYUGfBjeubeUmJ6Q@mail.gmail.com>
Date: Fri, 1 Mar 2024 13:44:56 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: linux-kernel@...r.kernel.org
Cc: linux-tip-commits@...r.kernel.org, Uros Bizjak <ubizjak@...il.com>,
Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>, Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Josh Poimboeuf <jpoimboe@...hat.com>, x86@...nel.org
Subject: Re: [tip: x86/boot] x86/boot: Use 32-bit XOR to clear registers
On Fri, 1 Mar 2024 at 13:39, tip-bot2 for Uros Bizjak
<tip-bot2@...utronix.de> wrote:
>
> The following commit has been merged into the x86/boot branch of tip:
>
> Commit-ID: 721f791ce1cddfa5f2bf524ac14741bfa0f72697
> Gitweb: https://git.kernel.org/tip/721f791ce1cddfa5f2bf524ac14741bfa0f72697
> Author: Uros Bizjak <ubizjak@...il.com>
> AuthorDate: Wed, 24 Jan 2024 11:38:59 +01:00
> Committer: Ingo Molnar <mingo@...nel.org>
> CommitterDate: Fri, 01 Mar 2024 12:47:37 +01:00
>
> x86/boot: Use 32-bit XOR to clear registers
>
> x86_64 zero extends 32-bit operations, so for 64-bit operands,
> XORL r32,r32 is functionally equal to XORQ r64,r64, but avoids
> a REX prefix byte when legacy registers are used.
>
.. and so this change is pointless churn when not using legacy
registers, right?
> Slightly smaller code generated, no change in functionality.
>
> Signed-off-by: Uros Bizjak <ubizjak@...il.com>
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> Cc: Andy Lutomirski <luto@...nel.org>
> Cc: Brian Gerst <brgerst@...il.com>
> Cc: Denys Vlasenko <dvlasenk@...hat.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Josh Poimboeuf <jpoimboe@...hat.com>
> Cc: Ard Biesheuvel <ardb@...nel.org>
> Link: https://lore.kernel.org/r/20240124103859.611372-1-ubizjak@gmail.com
> ---
> arch/x86/kernel/head_64.S | 6 +++---
> arch/x86/kernel/sev_verify_cbit.S | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index d295bf6..86136a7 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -169,7 +169,7 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
> ANNOTATE_NOENDBR
>
> /* Clear %R15 which holds the boot_params pointer on the boot CPU */
> - xorq %r15, %r15
> + xorl %r15d, %r15d
>
0: 4d 31 ff xor %r15,%r15
3: 45 31 ff xor %r15d,%r15d
> /*
> * Retrieve the modifier (SME encryption mask if SME is active) to be
> @@ -178,7 +178,7 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
> #ifdef CONFIG_AMD_MEM_ENCRYPT
> movq sme_me_mask, %rax
> #else
> - xorq %rax, %rax
> + xorl %eax, %eax
> #endif
>
This conflicts with my RIP-relative boot cleanup series.
> /* Form the CR3 value being sure to include the CR3 modifier */
> @@ -295,7 +295,7 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL)
>
> .Llookup_AP:
> /* EAX contains the APIC ID of the current CPU */
> - xorq %rcx, %rcx
> + xorl %ecx, %ecx
> leaq cpuid_to_apicid(%rip), %rbx
>
> .Lfind_cpunr:
> diff --git a/arch/x86/kernel/sev_verify_cbit.S b/arch/x86/kernel/sev_verify_cbit.S
> index 3355e27..1ab65f6 100644
> --- a/arch/x86/kernel/sev_verify_cbit.S
> +++ b/arch/x86/kernel/sev_verify_cbit.S
> @@ -77,7 +77,7 @@ SYM_FUNC_START(sev_verify_cbit)
> * The check failed, prevent any forward progress to prevent ROP
> * attacks, invalidate the stack and go into a hlt loop.
> */
> - xorq %rsp, %rsp
> + xorl %esp, %esp
> subq $0x1000, %rsp
> 2: hlt
> jmp 2b
Powered by blists - more mailing lists