All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Orzel <michal.orzel@arm.com>
To: Julien Grall <julien@xen.org>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>
Subject: Re: [PATCH] xen/arm64: Zero the top 32 bits of gp registers on entry...
Date: Tue, 7 Dec 2021 09:37:43 +0100	[thread overview]
Message-ID: <dc114877-b9da-7a5b-260d-b9438cddd777@arm.com> (raw)
In-Reply-To: <f3573439-4893-440f-54e1-fdeba3eb4508@xen.org>

Hi Julien,

On 06.12.2021 16:29, Julien Grall wrote:
> Hi,
> 
> On 06/12/2021 14:20, Michal Orzel wrote:
>> to hypervisor when switching to AArch32 state.
>>
I will change to "from AArch32 state".
>> According to section D1.20.2 of Arm Arm(DDI 0487A.j):
>> "If the general-purpose register was accessible from AArch32 state the
>> upper 32 bits either become zero, or hold the value that the same
>> architectural register held before any AArch32 execution.
>> The choice between these two options is IMPLEMENTATIONDEFINED"
> 
> Typo: Missing space between IMPLEMENTATION and DEFINED.
> 
Ok.
>>
>> Currently Xen does not ensure that the top 32 bits are zeroed and this
>> needs to be fixed.
> 
> Can you outline why this is a problem and why we need to protect? IIRC, the main concern is Xen may misinterpret what the guest requested but we are not concerned about Xen using wrong value.
> 
I would say:
"
The reason why this is a problem is that there are places in Xen where we assume that top 32bits are zero for AArch32 guests.
If they are not, this can lead to misinterpretation of Xen regarding what the guest requested.
For example hypercalls returning an error encoded in a signed long like do_sched_op, do_hmv_op, do_memory_op would return -ENOSYS
if the command passed as the first argument was clobbered,
"
>>
>> Fix this bug by zeroing the upper 32 bits of these registers on an
>> entry to hypervisor when switching to AArch32 state.
>>
>> Set default value of parameter compat of macro entry to 0 (AArch64 mode
>> as we are on 64-bit hypervisor) to avoid checking if parameter is blank
>> when not passed.
> 
> Which error do you see otherwise? Is it a compilation error?
> 
Yes, this is a compilation error. The errors appear at each line when "entry" is called without passing value for "compat".
So basically in all the places where entry is called with hyp=1.
When taking the current patch and removing default value for compat you will get:
```
entry.S:254: Error: ".endif" without ".if"
entry.S:258: Error: symbol `.if' is already defined
entry.S:258: Error: ".endif" without ".if"
entry.S:262: Error: symbol `.if' is already defined
entry.S:262: Error: ".endif" without ".if"
entry.S:266: Error: symbol `.if' is already defined
entry.S:266: Error: ".endif" without ".if"
entry.S:278: Error: symbol `.if' is already defined
entry.S:278: Error: ".endif" without ".if"
entry.S:292: Error: symbol `.if' is already defined
entry.S:292: Error: ".endif" without ".if"
entry.S:317: Error: symbol `.if' is already defined
entry.S:317: Error: ".endif" without ".if"
```

>>
>> Signed-off-by: Michal Orzel <michal.orzel@arm.com>
>> ---
>>   xen/arch/arm/arm64/entry.S | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
>> index fc3811ad0a..d364128175 100644
>> --- a/xen/arch/arm/arm64/entry.S
>> +++ b/xen/arch/arm/arm64/entry.S
>> @@ -109,8 +109,16 @@
>>    * If 0, we rely on the on x0/x1 to have been saved at the correct
>>    * position on the stack before.
>>    */
>> -        .macro  entry, hyp, compat, save_x0_x1=1
>> +        .macro  entry, hyp, compat=0, save_x0_x1=1
>>           sub     sp, sp, #(UREGS_SPSR_el1 - UREGS_LR) /* CPSR, PC, SP, LR */
>> +
>> +        /* Zero the upper 32 bits of the registers when switching to AArch32 */
>> +        .if \compat == 1      /* AArch32 mode */
>> +        .irp nr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29
>> +        mov w\nr, w\nr
>> +        .endr
>> +        .endif
> 
> So Jan mentioned, the x0/x1 may have already been saved. So you may need to fetch them from the stack and then clobber the top 32-bit.
> 
So I would do the following:
-fetch x0/x1 from the stack
-clobber them
-store them again on the stack

/*
 * Zero the upper 32 bits of the gp registers when switching
 * from AArch32.
 */
.if \compat == 1      /* AArch32 mode */

/* x0/x1 have already been saved so fetch them to zero top 32 bits */
.if \save_x0_x1 == 0
ldp     x0, x1, [sp], #(UREGS_kernel_sizeof - UREGS_X0)
.endif

.irp nr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29
mov w\nr, w\nr
.endr

.if \save_x0_x1 == 0
stp     x0, x1, [sp, #-(UREGS_kernel_sizeof - UREGS_X0)]
.endif

.endif

> Cheers,
> 

Cheers,
Michal


  reply	other threads:[~2021-12-07  8:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 14:20 [PATCH] xen/arm64: Zero the top 32 bits of gp registers on entry Michal Orzel
2021-12-06 14:45 ` Jan Beulich
2021-12-06 15:29 ` Julien Grall
2021-12-07  8:37   ` Michal Orzel [this message]
2021-12-07  9:05     ` Bertrand Marquis
2021-12-07  9:55     ` Jan Beulich
2021-12-07 19:25       ` Julien Grall
2021-12-07 19:11     ` Julien Grall
2021-12-08  7:20       ` Jan Beulich
2021-12-08  9:55         ` Julien Grall
2021-12-08 10:18           ` Jan Beulich
2021-12-14  9:17           ` Michal Orzel
2021-12-14  9:33             ` Julien Grall
2021-12-14  9:51               ` Michal Orzel
2021-12-14 10:01                 ` Jan Beulich
2021-12-14 10:10                   ` Michal Orzel
2021-12-14 11:01                   ` Julien Grall
2021-12-14 11:30                     ` Julien Grall
2021-12-15  9:27                       ` Michal Orzel
2021-12-15  9:35                         ` Jan Beulich
2021-12-15  9:48                           ` Michal Orzel
2021-12-15 10:32                             ` Jan Beulich
2021-12-15 10:40                               ` Michal Orzel
2021-12-15 18:25                                 ` Julien Grall
2021-12-16  7:14                                   ` Michal Orzel
2021-12-15 18:20                           ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc114877-b9da-7a5b-260d-b9438cddd777@arm.com \
    --to=michal.orzel@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.