[PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Juergen Gross]

xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
most only once during early boot, is clobbering %rbx. Depending on
whether the caller relies on %rbx to be preserved across the call or
not, this clobbering might result in an early crash of the system.

This can be avoided by not modifying %rbx in xen_hypercall_hvm().

Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/xen/xen-head.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 9252652afe59..4378b817ed32 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
 	pop %ebx
 	pop %eax
 #else
-	lea xen_hypercall_amd(%rip), %rbx
-	cmp %rax, %rbx
+	cmp xen_hypercall_amd(%rip), %rax
 #ifdef CONFIG_FRAME_POINTER
 	pop %rax	/* Dummy pop. */
 #endif
-- 
2.43.0

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Andrew Cooper]

On 05/02/2025 9:10 am, Juergen Gross wrote:
> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
> most only once during early boot, is clobbering %rbx. Depending on
> whether the caller relies on %rbx to be preserved across the call or
> not, this clobbering might result in an early crash of the system.
>
> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
>
> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/xen/xen-head.S | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 9252652afe59..4378b817ed32 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)

The 32bit case, out of context up here, also clobbers %ebx.

~Andrew

>  	pop %ebx
>  	pop %eax
>  #else
> -	lea xen_hypercall_amd(%rip), %rbx
> -	cmp %rax, %rbx
> +	cmp xen_hypercall_amd(%rip), %rax
>  #ifdef CONFIG_FRAME_POINTER
>  	pop %rax	/* Dummy pop. */
>  #endif

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1086 bytes --]

On 05.02.25 10:16, Andrew Cooper wrote:
> On 05/02/2025 9:10 am, Juergen Gross wrote:
>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
>> most only once during early boot, is clobbering %rbx. Depending on
>> whether the caller relies on %rbx to be preserved across the call or
>> not, this clobbering might result in an early crash of the system.
>>
>> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
>>
>> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/xen/xen-head.S | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>> index 9252652afe59..4378b817ed32 100644
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
> 
> The 32bit case, out of context up here, also clobbers %ebx.
> 
> ~Andrew
> 
>>   	pop %ebx

It does not, as this part of the context is showing.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Andrew Cooper]

On 05/02/2025 9:17 am, Jürgen Groß wrote:
> On 05.02.25 10:16, Andrew Cooper wrote:
>> On 05/02/2025 9:10 am, Juergen Gross wrote:
>>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
>>> most only once during early boot, is clobbering %rbx. Depending on
>>> whether the caller relies on %rbx to be preserved across the call or
>>> not, this clobbering might result in an early crash of the system.
>>>
>>> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
>>>
>>> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>   arch/x86/xen/xen-head.S | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>>> index 9252652afe59..4378b817ed32 100644
>>> --- a/arch/x86/xen/xen-head.S
>>> +++ b/arch/x86/xen/xen-head.S
>>> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
>>
>> The 32bit case, out of context up here, also clobbers %ebx.
>>
>> ~Andrew
>>
>>>       pop %ebx
>
> It does not, as this part of the context is showing.

Hmm, so it is, and worse, it can't be changed to match the 64bit side. 
That's nasty.

But while I'm here looking at the code, what's up with

#ifdef CONFIG_FRAME_POINTER
        pushq $0        /* Dummy push for stack alignment. */
#endif

?

That's covered by FRAME_{START,END} normally, and Linux's preferred
stack alignment is 8 not 16.

~Andrew

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Jan Beulich]

On 05.02.2025 10:10, Juergen Gross wrote:
> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
> most only once during early boot, is clobbering %rbx. Depending on
> whether the caller relies on %rbx to be preserved across the call or
> not, this clobbering might result in an early crash of the system.
> 
> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
> 
> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
>  arch/x86/xen/xen-head.S | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
> index 9252652afe59..4378b817ed32 100644
> --- a/arch/x86/xen/xen-head.S
> +++ b/arch/x86/xen/xen-head.S
> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
>  	pop %ebx
>  	pop %eax
>  #else
> -	lea xen_hypercall_amd(%rip), %rbx
> -	cmp %rax, %rbx

There's no memory access here, but ...

> +	cmp xen_hypercall_amd(%rip), %rax

... you now read from memory here. That can't be right. Afaict the original
use of LEA needs to stay, just with a different scratch register.

Jan

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1850 bytes --]

On 05.02.25 10:38, Andrew Cooper wrote:
> On 05/02/2025 9:17 am, Jürgen Groß wrote:
>> On 05.02.25 10:16, Andrew Cooper wrote:
>>> On 05/02/2025 9:10 am, Juergen Gross wrote:
>>>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
>>>> most only once during early boot, is clobbering %rbx. Depending on
>>>> whether the caller relies on %rbx to be preserved across the call or
>>>> not, this clobbering might result in an early crash of the system.
>>>>
>>>> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
>>>>
>>>> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>>    arch/x86/xen/xen-head.S | 3 +--
>>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>>>> index 9252652afe59..4378b817ed32 100644
>>>> --- a/arch/x86/xen/xen-head.S
>>>> +++ b/arch/x86/xen/xen-head.S
>>>> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
>>>
>>> The 32bit case, out of context up here, also clobbers %ebx.
>>>
>>> ~Andrew
>>>
>>>>        pop %ebx
>>
>> It does not, as this part of the context is showing.
> 
> Hmm, so it is, and worse, it can't be changed to match the 64bit side.
> That's nasty.
> 
> But while I'm here looking at the code, what's up with
> 
> #ifdef CONFIG_FRAME_POINTER
>          pushq $0        /* Dummy push for stack alignment. */
> #endif
> 
> ?
> 
> That's covered by FRAME_{START,END} normally, and Linux's preferred
> stack alignment is 8 not 16.

I've added this due to a review comment by Jan. As he is more into ABI
matters, I believed him.

Google is telling me you are right, so I'll remove those extra hunks in
V2 of the patch adding FRAME_END.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 1306 bytes --]

On 05.02.25 10:54, Jan Beulich wrote:
> On 05.02.2025 10:10, Juergen Gross wrote:
>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
>> most only once during early boot, is clobbering %rbx. Depending on
>> whether the caller relies on %rbx to be preserved across the call or
>> not, this clobbering might result in an early crash of the system.
>>
>> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
>>
>> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>   arch/x86/xen/xen-head.S | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>> index 9252652afe59..4378b817ed32 100644
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
>>   	pop %ebx
>>   	pop %eax
>>   #else
>> -	lea xen_hypercall_amd(%rip), %rbx
>> -	cmp %rax, %rbx
> 
> There's no memory access here, but ...
> 
>> +	cmp xen_hypercall_amd(%rip), %rax
> 
> ... you now read from memory here. That can't be right. Afaict the original
> use of LEA needs to stay, just with a different scratch register.

Oh, right. Thanks for noticing.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH] x86/xen: fix xen_hypercall_hvm() to not clobber %rbx

[Jan Beulich]

On 05.02.2025 11:04, Jürgen Groß wrote:
> On 05.02.25 10:38, Andrew Cooper wrote:
>> On 05/02/2025 9:17 am, Jürgen Groß wrote:
>>> On 05.02.25 10:16, Andrew Cooper wrote:
>>>> On 05/02/2025 9:10 am, Juergen Gross wrote:
>>>>> xen_hypercall_hvm(), which is used when running as a Xen PVH guest at
>>>>> most only once during early boot, is clobbering %rbx. Depending on
>>>>> whether the caller relies on %rbx to be preserved across the call or
>>>>> not, this clobbering might result in an early crash of the system.
>>>>>
>>>>> This can be avoided by not modifying %rbx in xen_hypercall_hvm().
>>>>>
>>>>> Fixes: b4845bb63838 ("x86/xen: add central hypercall functions")
>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>> ---
>>>>>    arch/x86/xen/xen-head.S | 3 +--
>>>>>    1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>>>>> index 9252652afe59..4378b817ed32 100644
>>>>> --- a/arch/x86/xen/xen-head.S
>>>>> +++ b/arch/x86/xen/xen-head.S
>>>>> @@ -117,8 +117,7 @@ SYM_FUNC_START(xen_hypercall_hvm)
>>>>
>>>> The 32bit case, out of context up here, also clobbers %ebx.
>>>>
>>>> ~Andrew
>>>>
>>>>>        pop %ebx
>>>
>>> It does not, as this part of the context is showing.
>>
>> Hmm, so it is, and worse, it can't be changed to match the 64bit side.
>> That's nasty.
>>
>> But while I'm here looking at the code, what's up with
>>
>> #ifdef CONFIG_FRAME_POINTER
>>          pushq $0        /* Dummy push for stack alignment. */
>> #endif
>>
>> ?
>>
>> That's covered by FRAME_{START,END} normally, and Linux's preferred
>> stack alignment is 8 not 16.
> 
> I've added this due to a review comment by Jan. As he is more into ABI
> matters, I believed him.
> 
> Google is telling me you are right, so I'll remove those extra hunks in
> V2 of the patch adding FRAME_END.

Oh, I'm sorry for misleading you. Clearly I must have been mis-remembering
(or things may have changed, and I should have re-checked).

Jan