linux-kernel - Re: [tip:x86/pti] x86/entry/64: Introduce the PUSH_AND_CLEAN

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6217451a-21ea-5fc3-54f7-1e333452dcda@redhat.com>
Date:   Mon, 12 Feb 2018 14:43:50 +0100
From:   Denys Vlasenko <dvlasenk@...hat.com>
To:     David Laight <David.Laight@...LAB.COM>,
        "hpa@...or.com" <hpa@...or.com>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux@...inikbrodowski.net" <linux@...inikbrodowski.net>,
        "brgerst@...il.com" <brgerst@...il.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "linux-tip-commits@...r.kernel.org" 
        <linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/pti] x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS
 macro

On 02/12/2018 02:36 PM, David Laight wrote:
> From: Denys Vlasenko
>> Sent: 12 February 2018 13:29
> ...
>>>
>>> x86/entry/64: Introduce the PUSH_AND_CLEAN_REGS macro
>>>
>>> Those instances where ALLOC_PT_GPREGS_ON_STACK is called just before
>>> SAVE_AND_CLEAR_REGS can trivially be replaced by PUSH_AND_CLEAN_REGS.
>>> This macro uses PUSH instead of MOV and should therefore be faster, at
>>> least on newer CPUs.
> ...
>>> Link: http://lkml.kernel.org/r/20180211104949.12992-5-linux@dominikbrodowski.net
>>> Signed-off-by: Ingo Molnar <mingo@...nel.org>
>>> ---
>>>    arch/x86/entry/calling.h  | 36 ++++++++++++++++++++++++++++++++++++
>>>    arch/x86/entry/entry_64.S |  6 ++----
>>>    2 files changed, 38 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
>>> index a05cbb8..57b1b87 100644
>>> --- a/arch/x86/entry/calling.h
>>> +++ b/arch/x86/entry/calling.h
>>> @@ -137,6 +137,42 @@ For 32-bit we have the following conventions - kernel is built with
>>>    	UNWIND_HINT_REGS offset=\offset
>>>    	.endm
>>>
>>> +	.macro PUSH_AND_CLEAR_REGS
>>> +	/*
>>> +	 * Push registers and sanitize registers of values that a
>>> +	 * speculation attack might otherwise want to exploit. The
>>> +	 * lower registers are likely clobbered well before they
>>> +	 * could be put to use in a speculative execution gadget.
>>> +	 * Interleave XOR with PUSH for better uop scheduling:
>>> +	 */
>>> +	pushq   %rdi		/* pt_regs->di */
>>> +	pushq   %rsi		/* pt_regs->si */
>>> +	pushq   %rdx		/* pt_regs->dx */
>>> +	pushq   %rcx		/* pt_regs->cx */
>>> +	pushq   %rax		/* pt_regs->ax */
>>> +	pushq   %r8		/* pt_regs->r8 */
>>> +	xorq    %r8, %r8	/* nospec   r8 */
>>
>> xorq's are slower than xorl's on Silvermont/Knights Landing.
>> I propose using xorl instead.
> 
> Does using movq to copy the first zero to the other registers make
> the code any faster?
> 
> ISTR mov reg-reg is often implemented as a register rename rather than an
> alu operation.

xorl is implemented in register rename as well. Just, for some reason,
xorq did not get the same treatment on those CPUs.