linux-kernel - Re: [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen

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]

Date:   Sat, 21 Jul 2018 19:18:42 -0400
From:   "M. Vefa Bicakci" <m.v.b@...box.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        linux-kernel@...r.kernel.org
Cc:     Dominik Brodowski <linux@...inikbrodowski.net>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Juergen Gross <jgross@...e.com>,
        xen-devel@...ts.xenproject.org, x86@...nel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen

On 07/21/2018 05:19 PM, Boris Ostrovsky wrote:
> On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote:
>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>> index c7449f377a77..96e8ff34129e 100644
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -1129,7 +1129,7 @@ ENTRY(xen_failsafe_callback)
>>   	addq	$0x30, %rsp
>>   	UNWIND_HINT_IRET_REGS
>>   	pushq	$-1 /* orig_ax = -1 => not a system call */
>> -	PUSH_AND_CLEAR_REGS
>> +	PUSH_AND_CLEAR_REGS clear_rbx=0
> 
> 
> Do we need this at all? We are returning from the hypervisor here.
> 
> -boris
> 
>>   	ENCODE_FRAME_POINTER
>>   	jmp	error_exit
>>   END(xen_failsafe_callback)

Hello Boris,

If you are referring to the PUSH_AND_CLEAR_REGS macro itself, I am not sure;
however, not clearing the RBX register seemed to resolve the issues mentioned
in the commit message for me. Given Andy's comment though, I believe that the
approach in this patch may not be correct.

Thank you,

Vefa