[Xen-devel,01/13] xen/arm: domain: Zeroed the vCPU stack

Message ID 20180522174254.27551-2-julien.grall@arm.com
State New
Headers show
Series
  • xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263)
Related show

Commit Message

Julien Grall May 22, 2018, 5:42 p.m.
A stack is allocated per vCPU to be used by Xen. The allocation is done
with alloc_xenheap_pages that does not zero the memory returned. However
the top of the stack is containing information that will be used to
store the initial state of the vCPU (see struct cpu_info). Some of the
fields may not be initialized and will lead to use/leak bits of previous
memory in some cases on the first run of vCPU (AFAICT this only happen on
vCPU0 for Dom0).

While this is not strictly necessary, this patch zero the full stack to
avoid more leakage.

This is part of XSA-263.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/domain.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Stefano Stabellini May 25, 2018, 8:52 p.m. | #1
On Tue, 22 May 2018, Julien Grall wrote:
> A stack is allocated per vCPU to be used by Xen. The allocation is done
> with alloc_xenheap_pages that does not zero the memory returned. However
> the top of the stack is containing information that will be used to
> store the initial state of the vCPU (see struct cpu_info). Some of the
> fields may not be initialized and will lead to use/leak bits of previous
> memory in some cases on the first run of vCPU (AFAICT this only happen on
> vCPU0 for Dom0).
> 
> While this is not strictly necessary, this patch zero the full stack to
> avoid more leakage.

Well spotted! struct cpu_info is the only instance of these cases, I
suggest to zero only sizeof(struct cpu_info) to avoid having any impact
on the boot time.

After all, with this series we have the mitigation enabled all the time
in Xen for XSA-263. Or do you think there are other reasons to be
concerned?



> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/arch/arm/domain.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index ec0f042bf7..e7b33e92fb 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -540,6 +540,7 @@ void free_vcpu_struct(struct vcpu *v)
>  int vcpu_initialise(struct vcpu *v)
>  {
>      int rc = 0;
> +    unsigned int i;
>  
>      BUILD_BUG_ON( sizeof(struct cpu_info) > STACK_SIZE );
>  
> @@ -547,6 +548,9 @@ int vcpu_initialise(struct vcpu *v)
>      if ( v->arch.stack == NULL )
>          return -ENOMEM;
>  
> +    for ( i = 0; i < (1U << STACK_ORDER); i++ )
> +        clear_page(v->arch.stack + (PAGE_SIZE * i));
> +
>      v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
>                                             + STACK_SIZE
>                                             - sizeof(struct cpu_info));
> -- 
> 2.11.0
>
Julien Grall May 29, 2018, 10:27 a.m. | #2
Hi Stefano,

On 25/05/18 21:52, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> A stack is allocated per vCPU to be used by Xen. The allocation is done
>> with alloc_xenheap_pages that does not zero the memory returned. However
>> the top of the stack is containing information that will be used to
>> store the initial state of the vCPU (see struct cpu_info). Some of the
>> fields may not be initialized and will lead to use/leak bits of previous
>> memory in some cases on the first run of vCPU (AFAICT this only happen on
>> vCPU0 for Dom0).
>>
>> While this is not strictly necessary, this patch zero the full stack to
>> avoid more leakage.
> 
> Well spotted! struct cpu_info is the only instance of these cases, I
> suggest to zero only sizeof(struct cpu_info) to avoid having any impact
> on the boot time.

I really don't believe the impact is noticeable when you look at the 
rest of the domain creation.

> 
> After all, with this series we have the mitigation enabled all the time
> in Xen for XSA-263. Or do you think there are other reasons to be
> concerned?

This has nothing to do with XSA-263. This is more that it would be a 
good practice to zero anything by default rather than relying on the 
code to do the proper initialization. In the case of the stack it would 
be un-initialized value over code called by a domain or even assembly.

We already do that for all Domain specific structure but the stack.

I don't really particularly care to fully zeroed the stack if you don't 
want to see it.

Cheers,

>> This is part of XSA-263.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/arch/arm/domain.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index ec0f042bf7..e7b33e92fb 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -540,6 +540,7 @@ void free_vcpu_struct(struct vcpu *v)
>>   int vcpu_initialise(struct vcpu *v)
>>   {
>>       int rc = 0;
>> +    unsigned int i;
>>   
>>       BUILD_BUG_ON( sizeof(struct cpu_info) > STACK_SIZE );
>>   
>> @@ -547,6 +548,9 @@ int vcpu_initialise(struct vcpu *v)
>>       if ( v->arch.stack == NULL )
>>           return -ENOMEM;
>>   
>> +    for ( i = 0; i < (1U << STACK_ORDER); i++ )
>> +        clear_page(v->arch.stack + (PAGE_SIZE * i));
>> +
>>       v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
>>                                              + STACK_SIZE
>>                                              - sizeof(struct cpu_info));
>> -- 
>> 2.11.0
>>
Stefano Stabellini May 29, 2018, 9:41 p.m. | #3
On Tue, 29 May 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 25/05/18 21:52, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > A stack is allocated per vCPU to be used by Xen. The allocation is done
> > > with alloc_xenheap_pages that does not zero the memory returned. However
> > > the top of the stack is containing information that will be used to
> > > store the initial state of the vCPU (see struct cpu_info). Some of the
> > > fields may not be initialized and will lead to use/leak bits of previous
> > > memory in some cases on the first run of vCPU (AFAICT this only happen on
> > > vCPU0 for Dom0).
> > > 
> > > While this is not strictly necessary, this patch zero the full stack to
> > > avoid more leakage.
> > 
> > Well spotted! struct cpu_info is the only instance of these cases, I
> > suggest to zero only sizeof(struct cpu_info) to avoid having any impact
> > on the boot time.
> 
> I really don't believe the impact is noticeable when you look at the rest of
> the domain creation.
> 
> > 
> > After all, with this series we have the mitigation enabled all the time
> > in Xen for XSA-263. Or do you think there are other reasons to be
> > concerned?
> 
> This has nothing to do with XSA-263. This is more that it would be a good
> practice to zero anything by default rather than relying on the code to do the
> proper initialization. In the case of the stack it would be un-initialized
> value over code called by a domain or even assembly.
> 
> We already do that for all Domain specific structure but the stack.
> 
> I don't really particularly care to fully zeroed the stack if you don't want
> to see it.

I'd choose to only zero what we need.


> 
> > > This is part of XSA-263.
> > > 
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > ---
> > >   xen/arch/arm/domain.c | 4 ++++
> > >   1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > index ec0f042bf7..e7b33e92fb 100644
> > > --- a/xen/arch/arm/domain.c
> > > +++ b/xen/arch/arm/domain.c
> > > @@ -540,6 +540,7 @@ void free_vcpu_struct(struct vcpu *v)
> > >   int vcpu_initialise(struct vcpu *v)
> > >   {
> > >       int rc = 0;
> > > +    unsigned int i;
> > >         BUILD_BUG_ON( sizeof(struct cpu_info) > STACK_SIZE );
> > >   @@ -547,6 +548,9 @@ int vcpu_initialise(struct vcpu *v)
> > >       if ( v->arch.stack == NULL )
> > >           return -ENOMEM;
> > >   +    for ( i = 0; i < (1U << STACK_ORDER); i++ )
> > > +        clear_page(v->arch.stack + (PAGE_SIZE * i));
> > > +
> > >       v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
> > >                                              + STACK_SIZE
> > >                                              - sizeof(struct cpu_info));
> > > -- 
> > > 2.11.0
> > > 
> 
> -- 
> Julien Grall
>

Patch

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ec0f042bf7..e7b33e92fb 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -540,6 +540,7 @@  void free_vcpu_struct(struct vcpu *v)
 int vcpu_initialise(struct vcpu *v)
 {
     int rc = 0;
+    unsigned int i;
 
     BUILD_BUG_ON( sizeof(struct cpu_info) > STACK_SIZE );
 
@@ -547,6 +548,9 @@  int vcpu_initialise(struct vcpu *v)
     if ( v->arch.stack == NULL )
         return -ENOMEM;
 
+    for ( i = 0; i < (1U << STACK_ORDER); i++ )
+        clear_page(v->arch.stack + (PAGE_SIZE * i));
+
     v->arch.cpu_info = (struct cpu_info *)(v->arch.stack
                                            + STACK_SIZE
                                            - sizeof(struct cpu_info));