* [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-25 20:52 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync Julien Grall
` (12 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
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(+)
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack
2018-05-22 17:42 ` [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack Julien Grall
@ 2018-05-25 20:52 ` Stefano Stabellini
2018-05-29 10:27 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 20:52 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack
2018-05-25 20:52 ` Stefano Stabellini
@ 2018-05-29 10:27 ` Julien Grall
2018-05-29 21:41 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-29 10:27 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
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
>>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack
2018-05-29 10:27 ` Julien Grall
@ 2018-05-29 21:41 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-29 21:41 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
2018-05-22 17:42 ` [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 21:27 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on Julien Grall
` (11 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
This will improve readability for future changes.
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/arm64/entry.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index ffa9a1c492..e2344e565f 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -226,11 +226,11 @@ guest_sync:
mrs x1, esr_el2
lsr x1, x1, #HSR_EC_SHIFT /* x1 = ESR_EL2.EC */
cmp x1, #HSR_EC_HVC64
- b.ne 1f /* Not a HVC skip fastpath. */
+ b.ne guest_sync_slowpath /* Not a HVC skip fastpath. */
mrs x1, esr_el2
and x1, x1, #0xffff /* Check the immediate [0:16] */
- cbnz x1, 1f /* should be 0 for HVC #0 */
+ cbnz x1, guest_sync_slowpath /* should be 0 for HVC #0 */
/*
* Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
@@ -241,7 +241,7 @@ guest_sync:
* be encoded as an immediate for cmp.
*/
eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
- cbnz w0, 1f
+ cbnz w0, guest_sync_slowpath
/*
* Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,7 +250,7 @@ guest_sync:
mov x1, xzr
eret
-1:
+guest_sync_slowpath:
/*
* x0/x1 may have been scratch by the fast path above, so avoid
* to save them.
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync
2018-05-22 17:42 ` [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync Julien Grall
@ 2018-05-23 21:27 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 21:27 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> This will improve readability for future changes.
>
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/arch/arm/arm64/entry.S | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index ffa9a1c492..e2344e565f 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -226,11 +226,11 @@ guest_sync:
> mrs x1, esr_el2
> lsr x1, x1, #HSR_EC_SHIFT /* x1 = ESR_EL2.EC */
> cmp x1, #HSR_EC_HVC64
> - b.ne 1f /* Not a HVC skip fastpath. */
> + b.ne guest_sync_slowpath /* Not a HVC skip fastpath. */
>
> mrs x1, esr_el2
> and x1, x1, #0xffff /* Check the immediate [0:16] */
> - cbnz x1, 1f /* should be 0 for HVC #0 */
> + cbnz x1, guest_sync_slowpath /* should be 0 for HVC #0 */
>
> /*
> * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
> @@ -241,7 +241,7 @@ guest_sync:
> * be encoded as an immediate for cmp.
> */
> eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> - cbnz w0, 1f
> + cbnz w0, guest_sync_slowpath
>
> /*
> * Clobber both x0 and x1 to prevent leakage. Note that thanks
> @@ -250,7 +250,7 @@ guest_sync:
> mov x1, xzr
> eret
>
> -1:
> +guest_sync_slowpath:
> /*
> * x0/x1 may have been scratch by the fast path above, so avoid
> * to save them.
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
2018-05-22 17:42 ` [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack Julien Grall
2018-05-22 17:42 ` [PATCH 02/13] xen/arm64: entry: Use named label in guest_sync Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 21:34 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing Julien Grall
` (10 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
Some errata will rely on the SMCCC version which is detected by
psci_init().
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/setup.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1d6f6bf37e..ac93de4786 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -171,8 +171,6 @@ static void __init processor_id(void)
}
processor_setup();
-
- check_local_cpu_errata();
}
void dt_unreserved_regions(paddr_t s, paddr_t e,
@@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
nr_cpu_ids = cpus;
+ /*
+ * Some errata relies on SMCCC version which is detected by psci_init()
+ * (called from smp_init_cpus()).
+ */
+ check_local_cpu_errata();
+
init_xen_time();
gic_init();
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on
2018-05-22 17:42 ` [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on Julien Grall
@ 2018-05-23 21:34 ` Stefano Stabellini
2018-05-25 19:51 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 21:34 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> Some errata will rely on the SMCCC version which is detected by
> psci_init().
>
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/arch/arm/setup.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 1d6f6bf37e..ac93de4786 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -171,8 +171,6 @@ static void __init processor_id(void)
> }
>
> processor_setup();
> -
> - check_local_cpu_errata();
> }
>
> void dt_unreserved_regions(paddr_t s, paddr_t e,
> @@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
> nr_cpu_ids = cpus;
>
> + /*
> + * Some errata relies on SMCCC version which is detected by psci_init()
> + * (called from smp_init_cpus()).
> + */
> + check_local_cpu_errata();
> +
> init_xen_time();
>
> gic_init();
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on
2018-05-23 21:34 ` Stefano Stabellini
@ 2018-05-25 19:51 ` Julien Grall
2018-05-29 21:30 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-25 19:51 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 05/23/2018 10:34 PM, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> Some errata will rely on the SMCCC version which is detected by
>> psci_init().
>>
>> This is part of XSA-263.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Thank you for the review. On an internal review Andre's suggested to
move psci_init() outside smp_init_cpus(). Something like:
processor_id();
/* Need PSCI version for firmware based errata workarounds */
psci_init();
check_local_cpu_errata();
smp_init_cpus();
I am wondering whether it would be clearer to have. What do you think?
Cheers,
>
>> ---
>> xen/arch/arm/setup.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 1d6f6bf37e..ac93de4786 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -171,8 +171,6 @@ static void __init processor_id(void)
>> }
>>
>> processor_setup();
>> -
>> - check_local_cpu_errata();
>> }
>>
>> void dt_unreserved_regions(paddr_t s, paddr_t e,
>> @@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>> printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
>> nr_cpu_ids = cpus;
>>
>> + /*
>> + * Some errata relies on SMCCC version which is detected by psci_init()
>> + * (called from smp_init_cpus()).
>> + */
>> + check_local_cpu_errata();
>> +
>> init_xen_time();
>>
>> gic_init();
>> --
>> 2.11.0
>>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on
2018-05-25 19:51 ` Julien Grall
@ 2018-05-29 21:30 ` Stefano Stabellini
2018-05-30 9:17 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-29 21:30 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Fri, 25 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 05/23/2018 10:34 PM, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Some errata will rely on the SMCCC version which is detected by
> > > psci_init().
> > >
> > > This is part of XSA-263.
> > >
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> >
> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>
> Thank you for the review. On an internal review Andre's suggested to move
> psci_init() outside smp_init_cpus(). Something like:
>
> processor_id();
>
> /* Need PSCI version for firmware based errata workarounds */
> psci_init();
>
> check_local_cpu_errata();
>
> smp_init_cpus();
>
> I am wondering whether it would be clearer to have. What do you think?
That also works. I am fine either way, they both look OK to me.
>
> >
> > > ---
> > > xen/arch/arm/setup.c | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > > index 1d6f6bf37e..ac93de4786 100644
> > > --- a/xen/arch/arm/setup.c
> > > +++ b/xen/arch/arm/setup.c
> > > @@ -171,8 +171,6 @@ static void __init processor_id(void)
> > > }
> > > processor_setup();
> > > -
> > > - check_local_cpu_errata();
> > > }
> > > void dt_unreserved_regions(paddr_t s, paddr_t e,
> > > @@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> > > printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
> > > nr_cpu_ids = cpus;
> > > + /*
> > > + * Some errata relies on SMCCC version which is detected by
> > > psci_init()
> > > + * (called from smp_init_cpus()).
> > > + */
> > > + check_local_cpu_errata();
> > > +
> > > init_xen_time();
> > > gic_init();
> > > --
> > > 2.11.0
> > >
>
> --
> Julien Grall
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on
2018-05-29 21:30 ` Stefano Stabellini
@ 2018-05-30 9:17 ` Julien Grall
0 siblings, 0 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-30 9:17 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 05/29/2018 10:30 PM, Stefano Stabellini wrote:
> On Fri, 25 May 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 05/23/2018 10:34 PM, Stefano Stabellini wrote:
>>> On Tue, 22 May 2018, Julien Grall wrote:
>>>> Some errata will rely on the SMCCC version which is detected by
>>>> psci_init().
>>>>
>>>> This is part of XSA-263.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>
>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>>
>> Thank you for the review. On an internal review Andre's suggested to move
>> psci_init() outside smp_init_cpus(). Something like:
>>
>> processor_id();
>>
>> /* Need PSCI version for firmware based errata workarounds */
>> psci_init();
>>
>> check_local_cpu_errata();
>>
>> smp_init_cpus();
>>
>> I am wondering whether it would be clearer to have. What do you think?
>
> That also works. I am fine either way, they both look OK to me.
I will keep the current version then.
Cheers,
>
>
>>
>>>
>>>> ---
>>>> xen/arch/arm/setup.c | 8 ++++++--
>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>>>> index 1d6f6bf37e..ac93de4786 100644
>>>> --- a/xen/arch/arm/setup.c
>>>> +++ b/xen/arch/arm/setup.c
>>>> @@ -171,8 +171,6 @@ static void __init processor_id(void)
>>>> }
>>>> processor_setup();
>>>> -
>>>> - check_local_cpu_errata();
>>>> }
>>>> void dt_unreserved_regions(paddr_t s, paddr_t e,
>>>> @@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>>>> printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
>>>> nr_cpu_ids = cpus;
>>>> + /*
>>>> + * Some errata relies on SMCCC version which is detected by
>>>> psci_init()
>>>> + * (called from smp_init_cpus()).
>>>> + */
>>>> + check_local_cpu_errata();
>>>> +
>>>> init_xen_time();
>>>> gic_init();
>>>> --
>>>> 2.11.0
>>>>
>>
>> --
>> Julien Grall
>>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (2 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 03/13] xen/arm: setup: Check errata for boot CPU later on Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 21:57 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation Julien Grall
` (9 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.
A new capability is also allocated for that purpose, and a config
option.
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/Kconfig | 10 ++++++++++
xen/arch/arm/cpuerrata.c | 39 +++++++++++++++++++++++++++++++++++++++
xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 6 ++++++
5 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..0e2d027060 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
Allows a guest to use SBSA Generic UART as a console. The
SBSA Generic UART implements a subset of ARM PL011 UART.
+config ARM_SSBD
+ bool "Speculative Store Bypass Disable" if EXPERT = "y"
+ depends on HAS_ALTERNATIVE
+ default y
+ help
+ This enables mitigation of bypassing of previous stores by speculative
+ loads.
+
+ If unsure, say Y.
+
endmenu
menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..bcea2eb6e5 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
#endif
+#ifdef CONFIG_ARM_SSBD
+
+/*
+ * Assembly code may use the variable directly, so we need to make sure
+ * it fits in a register.
+ */
+DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
+
+static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
+{
+ struct arm_smccc_res res;
+ bool supported = true;
+
+ if ( smccc_ver < SMCCC_VERSION(1, 1) )
+ return false;
+
+ /*
+ * The probe function return value is either negative (unsupported
+ * or mitigated), positive (unaffected), or zero (requires
+ * mitigation). We only need to do anything in the last case.
+ */
+ arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+ ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
+ if ( (int)res.a0 != 0 )
+ supported = false;
+
+ if ( supported )
+ this_cpu(ssbd_callback_required) = 1;
+
+ return supported;
+}
+#endif
+
#define MIDR_RANGE(model, min, max) \
.matches = is_affected_midr_range, \
.midr_model = model, \
@@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
.enable = enable_ic_inv_hardening,
},
#endif
+#ifdef CONFIG_ARM_SSBD
+ {
+ .capability = ARM_SSBD,
+ .matches = has_ssbd_mitigation,
+ },
+#endif
{},
};
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 4e45b237c8..e628d3ff56 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void) \
CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
#undef CHECK_WORKAROUND_HELPER
+#ifdef CONFIG_ARM_SSBD
+
+#include <asm/current.h>
+
+DECLARE_PER_CPU(register_t, ssbd_callback_required);
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+ return this_cpu(ssbd_callback_required);
+}
+
+#else
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+ return false;
+}
+
+#endif
+
#endif /* __ARM_CPUERRATA_H__ */
/*
* Local variables:
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index e557a095af..2a5c075d3b 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -43,8 +43,9 @@
#define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
#define SKIP_CTXT_SWITCH_SERROR_SYNC 6
#define ARM_HARDEN_BRANCH_PREDICTOR 7
+#define ARM_SSBD 8
-#define ARM_NCAPS 8
+#define ARM_NCAPS 9
#ifndef __ASSEMBLY__
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 8342cc33fe..650744d28b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -258,6 +258,12 @@ struct arm_smccc_res {
ARM_SMCCC_OWNER_ARCH, \
0x8000)
+#define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_CONV_32, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x7FFF)
+
/* SMCCC error codes */
#define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
#define ARM_SMCCC_NOT_SUPPORTED (-1)
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-22 17:42 ` [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing Julien Grall
@ 2018-05-23 21:57 ` Stefano Stabellini
2018-05-23 22:31 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 21:57 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
> mechanism for detecting the SSBD mitigation.
>
> A new capability is also allocated for that purpose, and a config
> option.
>
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
> xen/arch/arm/Kconfig | 10 ++++++++++
> xen/arch/arm/cpuerrata.c | 39 +++++++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
> xen/include/asm-arm/cpufeature.h | 3 ++-
> xen/include/asm-arm/smccc.h | 6 ++++++
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 8174c0c635..0e2d027060 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
> Allows a guest to use SBSA Generic UART as a console. The
> SBSA Generic UART implements a subset of ARM PL011 UART.
>
> +config ARM_SSBD
> + bool "Speculative Store Bypass Disable" if EXPERT = "y"
> + depends on HAS_ALTERNATIVE
> + default y
> + help
> + This enables mitigation of bypassing of previous stores by speculative
> + loads.
I would add a reference to spectre v4. What do you think of:
This enables the mitigation of Spectre v4 attacks based on bypassing
of previous memory stores by speculative loads.
> + If unsure, say Y.
> +
> endmenu
>
> menu "ARM errata workaround via the alternative framework"
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 1baa20654b..bcea2eb6e5 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
>
> #endif
>
> +#ifdef CONFIG_ARM_SSBD
> +
> +/*
> + * Assembly code may use the variable directly, so we need to make sure
> + * it fits in a register.
> + */
> +DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
> +
> +static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> +{
> + struct arm_smccc_res res;
> + bool supported = true;
> +
> + if ( smccc_ver < SMCCC_VERSION(1, 1) )
> + return false;
> +
> + /*
> + * The probe function return value is either negative (unsupported
> + * or mitigated), positive (unaffected), or zero (requires
> + * mitigation). We only need to do anything in the last case.
> + */
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> + ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> + if ( (int)res.a0 != 0 )
> + supported = false;
> +
> + if ( supported )
> + this_cpu(ssbd_callback_required) = 1;
> +
> + return supported;
> +}
> +#endif
> +
> #define MIDR_RANGE(model, min, max) \
> .matches = is_affected_midr_range, \
> .midr_model = model, \
> @@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
> .enable = enable_ic_inv_hardening,
> },
> #endif
> +#ifdef CONFIG_ARM_SSBD
> + {
> + .capability = ARM_SSBD,
> + .matches = has_ssbd_mitigation,
> + },
> +#endif
> {},
> };
>
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index 4e45b237c8..e628d3ff56 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void) \
>
> CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
> CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
> +CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
>
> #undef CHECK_WORKAROUND_HELPER
>
> +#ifdef CONFIG_ARM_SSBD
> +
> +#include <asm/current.h>
> +
> +DECLARE_PER_CPU(register_t, ssbd_callback_required);
It is becoming more common to have per-cpu capabilities and workarounds
(or at least per MPIDR). Instead of adding this add-hoc variable, should
we make cpu_hwcaps per-cpu, then implement this check with
cpus_have_cap (that would become per-cpu as well)?
It looks like the code would be simpler.
> +static inline bool cpu_require_ssbd_mitigation(void)
> +{
> + return this_cpu(ssbd_callback_required);
> +}
> +
> +#else
> +
> +static inline bool cpu_require_ssbd_mitigation(void)
> +{
> + return false;
> +}
>
> +#endif
> +
> #endif /* __ARM_CPUERRATA_H__ */
> /*
> * Local variables:
> diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
> index e557a095af..2a5c075d3b 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -43,8 +43,9 @@
> #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
> #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
> #define ARM_HARDEN_BRANCH_PREDICTOR 7
> +#define ARM_SSBD 8
>
> -#define ARM_NCAPS 8
> +#define ARM_NCAPS 9
>
> #ifndef __ASSEMBLY__
>
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index 8342cc33fe..650744d28b 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -258,6 +258,12 @@ struct arm_smccc_res {
> ARM_SMCCC_OWNER_ARCH, \
> 0x8000)
>
> +#define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_CONV_32, \
> + ARM_SMCCC_OWNER_ARCH, \
> + 0x7FFF)
> +
> /* SMCCC error codes */
> #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
> #define ARM_SMCCC_NOT_SUPPORTED (-1)
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-23 21:57 ` Stefano Stabellini
@ 2018-05-23 22:31 ` Julien Grall
2018-05-25 20:51 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-23 22:31 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi,
On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
>> mechanism for detecting the SSBD mitigation.
>>
>> A new capability is also allocated for that purpose, and a config
>> option.
>>
>> This is part of XSA-263.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>> xen/arch/arm/Kconfig | 10 ++++++++++
>> xen/arch/arm/cpuerrata.c | 39 +++++++++++++++++++++++++++++++++++++++
>> xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
>> xen/include/asm-arm/cpufeature.h | 3 ++-
>> xen/include/asm-arm/smccc.h | 6 ++++++
>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>> index 8174c0c635..0e2d027060 100644
>> --- a/xen/arch/arm/Kconfig
>> +++ b/xen/arch/arm/Kconfig
>> @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
>> Allows a guest to use SBSA Generic UART as a console. The
>> SBSA Generic UART implements a subset of ARM PL011 UART.
>>
>> +config ARM_SSBD
>> + bool "Speculative Store Bypass Disable" if EXPERT = "y"
>> + depends on HAS_ALTERNATIVE
>> + default y
>> + help
>> + This enables mitigation of bypassing of previous stores by speculative
>> + loads.
>
> I would add a reference to spectre v4. What do you think of:
>
> This enables the mitigation of Spectre v4 attacks based on bypassing
> of previous memory stores by speculative loads.
Well, the real name is SSBD (Speculative Store Bypass Disable). AFAIK,
Spectre only refers to variant 1 and 2 so far. This one has no fancy
name and the specifications is using SSBD.
>> + If unsure, say Y.
>> +
>> endmenu
>>
>> menu "ARM errata workaround via the alternative framework"
>> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
>> index 1baa20654b..bcea2eb6e5 100644
>> --- a/xen/arch/arm/cpuerrata.c
>> +++ b/xen/arch/arm/cpuerrata.c
>> @@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
>>
>> #endif
>>
>> +#ifdef CONFIG_ARM_SSBD
>> +
>> +/*
>> + * Assembly code may use the variable directly, so we need to make sure
>> + * it fits in a register.
>> + */
>> +DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
>> +
>> +static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
>> +{
>> + struct arm_smccc_res res;
>> + bool supported = true;
>> +
>> + if ( smccc_ver < SMCCC_VERSION(1, 1) )
>> + return false;
>> +
>> + /*
>> + * The probe function return value is either negative (unsupported
>> + * or mitigated), positive (unaffected), or zero (requires
>> + * mitigation). We only need to do anything in the last case.
>> + */
>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
>> + ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
>> + if ( (int)res.a0 != 0 )
>> + supported = false;
>> +
>> + if ( supported )
>> + this_cpu(ssbd_callback_required) = 1;
>> +
>> + return supported;
>> +}
>> +#endif
>> +
>> #define MIDR_RANGE(model, min, max) \
>> .matches = is_affected_midr_range, \
>> .midr_model = model, \
>> @@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
>> .enable = enable_ic_inv_hardening,
>> },
>> #endif
>> +#ifdef CONFIG_ARM_SSBD
>> + {
>> + .capability = ARM_SSBD,
>> + .matches = has_ssbd_mitigation,
>> + },
>> +#endif
>> {},
>> };
>>
>> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
>> index 4e45b237c8..e628d3ff56 100644
>> --- a/xen/include/asm-arm/cpuerrata.h
>> +++ b/xen/include/asm-arm/cpuerrata.h
>> @@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void) \
>>
>> CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
>> CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
>> +CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
>>
>> #undef CHECK_WORKAROUND_HELPER
>>
>> +#ifdef CONFIG_ARM_SSBD
>> +
>> +#include <asm/current.h>
>> +
>> +DECLARE_PER_CPU(register_t, ssbd_callback_required);
>
> It is becoming more common to have per-cpu capabilities and workarounds
> (or at least per MPIDR).
Really? This is the first place where we need an ad-hoc boolean per-CPU.
For the hardening branch predictor, we have to store the vector pointer.
> Instead of adding this add-hoc variable, should
> we make cpu_hwcaps per-cpu, then implement this check with
> cpus_have_cap (that would become per-cpu as well)?
>
> It looks like the code would be simpler.
I don't see any benefits for that. Most of the workaround/features are
platform wide because they either use alternative or set/clear a bit in
the system registers.
Furthermore, as I wrote above the declaration, this is going to be used
in assembly code and we need something that can be tested in the less
possible number of instructions because The smccc function
ARM_ARCH_WORKAROUND_2 is going to be called very often.
Lastly, after the next patch, ssbd_callback_required and ARM_SSBD have
different meaning. The former indicates that runtime mitigation is
required, while the latter just indicate that the mitigation is present
(either runtime or forced enable).
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-23 22:31 ` Julien Grall
@ 2018-05-25 20:51 ` Stefano Stabellini
2018-05-25 23:54 ` Andrew Cooper
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 20:51 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Wed, 23 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
> > > mechanism for detecting the SSBD mitigation.
> > >
> > > A new capability is also allocated for that purpose, and a config
> > > option.
> > >
> > > This is part of XSA-263.
> > >
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > ---
> > > xen/arch/arm/Kconfig | 10 ++++++++++
> > > xen/arch/arm/cpuerrata.c | 39
> > > +++++++++++++++++++++++++++++++++++++++
> > > xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
> > > xen/include/asm-arm/cpufeature.h | 3 ++-
> > > xen/include/asm-arm/smccc.h | 6 ++++++
> > > 5 files changed, 78 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > index 8174c0c635..0e2d027060 100644
> > > --- a/xen/arch/arm/Kconfig
> > > +++ b/xen/arch/arm/Kconfig
> > > @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
> > > Allows a guest to use SBSA Generic UART as a console. The
> > > SBSA Generic UART implements a subset of ARM PL011 UART.
> > > +config ARM_SSBD
> > > + bool "Speculative Store Bypass Disable" if EXPERT = "y"
> > > + depends on HAS_ALTERNATIVE
> > > + default y
> > > + help
> > > + This enables mitigation of bypassing of previous stores by
> > > speculative
> > > + loads.
> >
> > I would add a reference to spectre v4. What do you think of:
> >
> > This enables the mitigation of Spectre v4 attacks based on bypassing
> > of previous memory stores by speculative loads.
>
> Well, the real name is SSBD (Speculative Store Bypass Disable). AFAIK, Spectre
> only refers to variant 1 and 2 so far. This one has no fancy name and the
> specifications is using SSBD.
Googling for Spectre Variant 4 returns twice as many results as Googling
for Speculative Store Bypass Disable. It doesn't matter what is the
official name for the security issue, I think we need to include a
reference to the most common name for it.
> > > + If unsure, say Y.
> > > +
> > > endmenu
> > > menu "ARM errata workaround via the alternative framework"
> > > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> > > index 1baa20654b..bcea2eb6e5 100644
> > > --- a/xen/arch/arm/cpuerrata.c
> > > +++ b/xen/arch/arm/cpuerrata.c
> > > @@ -235,6 +235,39 @@ static int enable_ic_inv_hardening(void *data)
> > > #endif
> > > +#ifdef CONFIG_ARM_SSBD
> > > +
> > > +/*
> > > + * Assembly code may use the variable directly, so we need to make sure
> > > + * it fits in a register.
> > > + */
> > > +DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
> > > +
> > > +static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> > > +{
> > > + struct arm_smccc_res res;
> > > + bool supported = true;
> > > +
> > > + if ( smccc_ver < SMCCC_VERSION(1, 1) )
> > > + return false;
> > > +
> > > + /*
> > > + * The probe function return value is either negative (unsupported
> > > + * or mitigated), positive (unaffected), or zero (requires
> > > + * mitigation). We only need to do anything in the last case.
> > > + */
> > > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> > > + ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> > > + if ( (int)res.a0 != 0 )
> > > + supported = false;
> > > +
> > > + if ( supported )
> > > + this_cpu(ssbd_callback_required) = 1;
> > > +
> > > + return supported;
> > > +}
> > > +#endif
> > > +
> > > #define MIDR_RANGE(model, min, max) \
> > > .matches = is_affected_midr_range, \
> > > .midr_model = model, \
> > > @@ -336,6 +369,12 @@ static const struct arm_cpu_capabilities arm_errata[]
> > > = {
> > > .enable = enable_ic_inv_hardening,
> > > },
> > > #endif
> > > +#ifdef CONFIG_ARM_SSBD
> > > + {
> > > + .capability = ARM_SSBD,
> > > + .matches = has_ssbd_mitigation,
> > > + },
> > > +#endif
> > > {},
> > > };
> > > diff --git a/xen/include/asm-arm/cpuerrata.h
> > > b/xen/include/asm-arm/cpuerrata.h
> > > index 4e45b237c8..e628d3ff56 100644
> > > --- a/xen/include/asm-arm/cpuerrata.h
> > > +++ b/xen/include/asm-arm/cpuerrata.h
> > > @@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void)
> > > \
> > > CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422,
> > > CONFIG_ARM_32)
> > > CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
> > > +CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
> > > #undef CHECK_WORKAROUND_HELPER
> > > +#ifdef CONFIG_ARM_SSBD
> > > +
> > > +#include <asm/current.h>
> > > +
> > > +DECLARE_PER_CPU(register_t, ssbd_callback_required);
> >
> > It is becoming more common to have per-cpu capabilities and workarounds
> > (or at least per MPIDR).
>
> Really? This is the first place where we need an ad-hoc boolean per-CPU. For
> the hardening branch predictor, we have to store the vector pointer.
>
> > Instead of adding this add-hoc variable, should
> > we make cpu_hwcaps per-cpu, then implement this check with
> > cpus_have_cap (that would become per-cpu as well)?
> >
> > It looks like the code would be simpler.
>
> I don't see any benefits for that. Most of the workaround/features are
> platform wide because they either use alternative or set/clear a bit in the
> system registers.
>
> Furthermore, as I wrote above the declaration, this is going to be used in
> assembly code and we need something that can be tested in the less possible
> number of instructions because The smccc function ARM_ARCH_WORKAROUND_2 is
> going to be called very often.
>
> Lastly, after the next patch, ssbd_callback_required and ARM_SSBD have
> different meaning. The former indicates that runtime mitigation is required,
> while the latter just indicate that the mitigation is present (either runtime
> or forced enable).
You are right. I was following up from the big.LITTLE series where not
all CPUs need the same workaround. On the call you pointed out that the
cpufeature framework is mostly to enable specific code workarounds in
Xen for some erratas. These dynamic code fixes have to be enabled on all
cores regardless on whether they are affected because they rely on
dynamic code patching. I see your point, and I agree we should keep
cpufeature as-is for now. I think I have a better suggestion in my
reply to patch #5.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-25 20:51 ` Stefano Stabellini
@ 2018-05-25 23:54 ` Andrew Cooper
2018-05-29 21:35 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Andrew Cooper @ 2018-05-25 23:54 UTC (permalink / raw)
To: Stefano Stabellini, Julien Grall; +Cc: xen-devel, andre.przywara
On 25/05/2018 21:51, Stefano Stabellini wrote:
> On Wed, 23 May 2018, Julien Grall wrote:
>> Hi,
>>
>> On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
>>> On Tue, 22 May 2018, Julien Grall wrote:
>>>> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
>>>> mechanism for detecting the SSBD mitigation.
>>>>
>>>> A new capability is also allocated for that purpose, and a config
>>>> option.
>>>>
>>>> This is part of XSA-263.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>> xen/arch/arm/Kconfig | 10 ++++++++++
>>>> xen/arch/arm/cpuerrata.c | 39
>>>> +++++++++++++++++++++++++++++++++++++++
>>>> xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
>>>> xen/include/asm-arm/cpufeature.h | 3 ++-
>>>> xen/include/asm-arm/smccc.h | 6 ++++++
>>>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>> index 8174c0c635..0e2d027060 100644
>>>> --- a/xen/arch/arm/Kconfig
>>>> +++ b/xen/arch/arm/Kconfig
>>>> @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
>>>> Allows a guest to use SBSA Generic UART as a console. The
>>>> SBSA Generic UART implements a subset of ARM PL011 UART.
>>>> +config ARM_SSBD
>>>> + bool "Speculative Store Bypass Disable" if EXPERT = "y"
>>>> + depends on HAS_ALTERNATIVE
>>>> + default y
>>>> + help
>>>> + This enables mitigation of bypassing of previous stores by
>>>> speculative
>>>> + loads.
>>> I would add a reference to spectre v4. What do you think of:
>>>
>>> This enables the mitigation of Spectre v4 attacks based on bypassing
>>> of previous memory stores by speculative loads.
>> Well, the real name is SSBD (Speculative Store Bypass Disable). AFAIK, Spectre
>> only refers to variant 1 and 2 so far. This one has no fancy name and the
>> specifications is using SSBD.
> Googling for Spectre Variant 4 returns twice as many results as Googling
> for Speculative Store Bypass Disable. It doesn't matter what is the
> official name for the security issue, I think we need to include a
> reference to the most common name for it.
"Speculative Store Bypass" is the agreed vendor-neutral name for the
issue. This is why all the mitigation is SSBD, where the D on the end
is Disable.
Google SP4 is a common name (but only covers one reporter of the issue),
whereas Spectre has nothing to do with this issue, and is definitely
wrong to use.
If in doubt, use SSB(D).
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-25 23:54 ` Andrew Cooper
@ 2018-05-29 21:35 ` Stefano Stabellini
2018-05-30 9:35 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-29 21:35 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Julien Grall, Stefano Stabellini, andre.przywara
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3014 bytes --]
On Sat, 26 May 2018, Andrew Cooper wrote:
> On 25/05/2018 21:51, Stefano Stabellini wrote:
> > On Wed, 23 May 2018, Julien Grall wrote:
> >> Hi,
> >>
> >> On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
> >>> On Tue, 22 May 2018, Julien Grall wrote:
> >>>> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
> >>>> mechanism for detecting the SSBD mitigation.
> >>>>
> >>>> A new capability is also allocated for that purpose, and a config
> >>>> option.
> >>>>
> >>>> This is part of XSA-263.
> >>>>
> >>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
> >>>> ---
> >>>> xen/arch/arm/Kconfig | 10 ++++++++++
> >>>> xen/arch/arm/cpuerrata.c | 39
> >>>> +++++++++++++++++++++++++++++++++++++++
> >>>> xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
> >>>> xen/include/asm-arm/cpufeature.h | 3 ++-
> >>>> xen/include/asm-arm/smccc.h | 6 ++++++
> >>>> 5 files changed, 78 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> >>>> index 8174c0c635..0e2d027060 100644
> >>>> --- a/xen/arch/arm/Kconfig
> >>>> +++ b/xen/arch/arm/Kconfig
> >>>> @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
> >>>> Allows a guest to use SBSA Generic UART as a console. The
> >>>> SBSA Generic UART implements a subset of ARM PL011 UART.
> >>>> +config ARM_SSBD
> >>>> + bool "Speculative Store Bypass Disable" if EXPERT = "y"
> >>>> + depends on HAS_ALTERNATIVE
> >>>> + default y
> >>>> + help
> >>>> + This enables mitigation of bypassing of previous stores by
> >>>> speculative
> >>>> + loads.
> >>> I would add a reference to spectre v4. What do you think of:
> >>>
> >>> This enables the mitigation of Spectre v4 attacks based on bypassing
> >>> of previous memory stores by speculative loads.
> >> Well, the real name is SSBD (Speculative Store Bypass Disable). AFAIK, Spectre
> >> only refers to variant 1 and 2 so far. This one has no fancy name and the
> >> specifications is using SSBD.
> > Googling for Spectre Variant 4 returns twice as many results as Googling
> > for Speculative Store Bypass Disable. It doesn't matter what is the
> > official name for the security issue, I think we need to include a
> > reference to the most common name for it.
>
> "Speculative Store Bypass" is the agreed vendor-neutral name for the
> issue. This is why all the mitigation is SSBD, where the D on the end
> is Disable.
>
> Google SP4 is a common name (but only covers one reporter of the issue),
> whereas Spectre has nothing to do with this issue, and is definitely
> wrong to use.
>
> If in doubt, use SSB(D).
I think we should definitely call it SSBD, I was just saying that it
might be helpful to include also "Variant 4" in the description, such
as:
This is also known as Variant 4.
to help users find the right results on Google. Anyway, given that you
are certainly better informed than me about it, I won't insist on this
point, I am OK without mentioning "Variant 4".
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
2018-05-29 21:35 ` Stefano Stabellini
@ 2018-05-30 9:35 ` Julien Grall
0 siblings, 0 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-30 9:35 UTC (permalink / raw)
To: Stefano Stabellini, Andrew Cooper; +Cc: xen-devel, andre.przywara
Hi,
On 05/29/2018 10:35 PM, Stefano Stabellini wrote:
> On Sat, 26 May 2018, Andrew Cooper wrote:
>> On 25/05/2018 21:51, Stefano Stabellini wrote:
>>> On Wed, 23 May 2018, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
>>>>> On Tue, 22 May 2018, Julien Grall wrote:
>>>>>> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
>>>>>> mechanism for detecting the SSBD mitigation.
>>>>>>
>>>>>> A new capability is also allocated for that purpose, and a config
>>>>>> option.
>>>>>>
>>>>>> This is part of XSA-263.
>>>>>>
>>>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>>>> ---
>>>>>> xen/arch/arm/Kconfig | 10 ++++++++++
>>>>>> xen/arch/arm/cpuerrata.c | 39
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>> xen/include/asm-arm/cpuerrata.h | 21 +++++++++++++++++++++
>>>>>> xen/include/asm-arm/cpufeature.h | 3 ++-
>>>>>> xen/include/asm-arm/smccc.h | 6 ++++++
>>>>>> 5 files changed, 78 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
>>>>>> index 8174c0c635..0e2d027060 100644
>>>>>> --- a/xen/arch/arm/Kconfig
>>>>>> +++ b/xen/arch/arm/Kconfig
>>>>>> @@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
>>>>>> Allows a guest to use SBSA Generic UART as a console. The
>>>>>> SBSA Generic UART implements a subset of ARM PL011 UART.
>>>>>> +config ARM_SSBD
>>>>>> + bool "Speculative Store Bypass Disable" if EXPERT = "y"
>>>>>> + depends on HAS_ALTERNATIVE
>>>>>> + default y
>>>>>> + help
>>>>>> + This enables mitigation of bypassing of previous stores by
>>>>>> speculative
>>>>>> + loads.
>>>>> I would add a reference to spectre v4. What do you think of:
>>>>>
>>>>> This enables the mitigation of Spectre v4 attacks based on bypassing
>>>>> of previous memory stores by speculative loads.
>>>> Well, the real name is SSBD (Speculative Store Bypass Disable). AFAIK, Spectre
>>>> only refers to variant 1 and 2 so far. This one has no fancy name and the
>>>> specifications is using SSBD.
>>> Googling for Spectre Variant 4 returns twice as many results as Googling
>>> for Speculative Store Bypass Disable. It doesn't matter what is the
>>> official name for the security issue, I think we need to include a
>>> reference to the most common name for it.
>>
>> "Speculative Store Bypass" is the agreed vendor-neutral name for the
>> issue. This is why all the mitigation is SSBD, where the D on the end
>> is Disable.
>>
>> Google SP4 is a common name (but only covers one reporter of the issue),
>> whereas Spectre has nothing to do with this issue, and is definitely
>> wrong to use.
>>
>> If in doubt, use SSB(D).
>
> I think we should definitely call it SSBD, I was just saying that it
> might be helpful to include also "Variant 4" in the description, such
> as:
>
> This is also known as Variant 4.
>
> to help users find the right results on Google.
There are enough hit with "Speculative Store Bypass Disable" for a user
to find what's going on.
> Anyway, given that you
> are certainly better informed than me about it, I won't insist on this
> point, I am OK without mentioning "Variant 4".
I would prefer to not mention it in the Kconfig.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (3 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 22:34 ` Stefano Stabellini
2018-05-23 23:23 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests Julien Grall
` (8 subsequent siblings)
13 siblings, 2 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
On a system where the firmware implements ARCH_WORKAROUND_2, it may be
useful to either permanently enable or disable the workaround for cases
where the user decides that they'd rather not get a trap overhead, and
keep the mitigation permanently on or off instead of switching it on
exception entry/exit.
In any case, default to mitigation being enabled.
At the same time provide a accessor to know the state of the mitigation.
SIgned-off-by: Julien Grall <julien.grall@arm.com>
---
docs/misc/xen-command-line.markdown | 18 ++++++
xen/arch/arm/cpuerrata.c | 115 ++++++++++++++++++++++++++++++++----
xen/include/asm-arm/cpuerrata.h | 21 +++++++
xen/include/asm-arm/smccc.h | 1 +
4 files changed, 144 insertions(+), 11 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 8712a833a2..962028b6ed 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 670ms. Any number
is being interpreted as a custom timeout in milliseconds. Zero or boolean
false disable the quirk workaround, which is also the default.
+### spec-ctrl (Arm)
+> `= List of [ ssbd=force-disable|runtime|force-enable ]`
+
+Controls for speculative execution sidechannel mitigations.
+
+The option `ssbd=` is used to control the state of Speculative Store
+Bypass Disable (SSBD) mitigation.
+
+* `ssbd=force-disable` will keep the mitigation permanently off. The guest
+will not be able to control the state of the mitigation.
+* `ssbd=runtime` will always turn on the mitigation when running in the
+hypervisor context. The guest will be to turn on/off the mitigation for
+itself by using the firmware interface ARCH\_WORKAROUND\_2.
+* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
+not be able to control the state of the mitigation.
+
+By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
+
### spec-ctrl (x86)
> `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}=<bool> ]`
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index bcea2eb6e5..f921721a66 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
#ifdef CONFIG_ARM_SSBD
+enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
+
+static int __init parse_spec_ctrl(const char *s)
+{
+ const char *ss;
+ int rc = 0;
+
+ do {
+ ss = strchr(s, ',');
+ if ( !ss )
+ ss = strchr(s, '\0');
+
+ if ( !strncmp(s, "ssbd=", 5) )
+ {
+ s += 5;
+
+ if ( !strncmp(s, "force-disable", ss - s) )
+ ssbd_state = ARM_SSBD_FORCE_DISABLE;
+ else if ( !strncmp(s, "runtime", ss - s) )
+ ssbd_state = ARM_SSBD_RUNTIME;
+ else if ( !strncmp(s, "force-enable", ss - s) )
+ ssbd_state = ARM_SSBD_FORCE_ENABLE;
+ else
+ rc = -EINVAL;
+ }
+ else
+ rc = -EINVAL;
+
+ s = ss + 1;
+ } while ( *ss );
+
+ return rc;
+}
+custom_param("spec-ctrl", parse_spec_ctrl);
+
/*
* Assembly code may use the variable directly, so we need to make sure
* it fits in a register.
@@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
{
struct arm_smccc_res res;
- bool supported = true;
+ bool required = true;
if ( smccc_ver < SMCCC_VERSION(1, 1) )
return false;
- /*
- * The probe function return value is either negative (unsupported
- * or mitigated), positive (unaffected), or zero (requires
- * mitigation). We only need to do anything in the last case.
- */
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
- if ( (int)res.a0 != 0 )
- supported = false;
- if ( supported )
- this_cpu(ssbd_callback_required) = 1;
+ switch ( (int)res.a0 )
+ {
+ case ARM_SMCCC_NOT_SUPPORTED:
+ ssbd_state = ARM_SSBD_UNKNOWN;
+ return false;
+
+ case ARM_SMCCC_NOT_REQUIRED:
+ ssbd_state = ARM_SSBD_MITIGATED;
+ return false;
+
+ case ARM_SMCCC_SUCCESS:
+ required = true;
+ break;
+
+ case 1: /* Mitigation not required on this CPU. */
+ required = false;
+ break;
+
+ default:
+ ASSERT_UNREACHABLE();
+ return false;
+ }
+
+ switch ( ssbd_state )
+ {
+ case ARM_SSBD_FORCE_DISABLE:
+ {
+ static bool once = true;
+
+ if ( once )
+ printk("%s disabled from command-line\n", entry->desc);
+ once = false;
+
+ arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+ required = false;
+
+ break;
+ }
+
+ case ARM_SSBD_RUNTIME:
+ if ( required )
+ {
+ this_cpu(ssbd_callback_required) = 1;
+ arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+ }
+
+ break;
+
+ case ARM_SSBD_FORCE_ENABLE:
+ {
+ static bool once = true;
+
+ if ( once )
+ printk("%s forced from command-line\n", entry->desc);
+ once = false;
+
+ arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+ required = true;
+
+ break;
+ }
+
+ default:
+ ASSERT_UNREACHABLE();
+ return false;
+ }
- return supported;
+ return required;
}
#endif
@@ -371,6 +463,7 @@ static const struct arm_cpu_capabilities arm_errata[] = {
#endif
#ifdef CONFIG_ARM_SSBD
{
+ .desc = "Speculative Store Bypass Disabled",
.capability = ARM_SSBD,
.matches = has_ssbd_mitigation,
},
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index e628d3ff56..7fbb3dc0be 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
#undef CHECK_WORKAROUND_HELPER
+enum ssbd_state
+{
+ ARM_SSBD_UNKNOWN,
+ ARM_SSBD_FORCE_DISABLE,
+ ARM_SSBD_RUNTIME,
+ ARM_SSBD_FORCE_ENABLE,
+ ARM_SSBD_MITIGATED,
+};
+
#ifdef CONFIG_ARM_SSBD
#include <asm/current.h>
+extern enum ssbd_state ssbd_state;
+
+static inline enum ssbd_state get_ssbd_state(void)
+{
+ return ssbd_state;
+}
+
DECLARE_PER_CPU(register_t, ssbd_callback_required);
static inline bool cpu_require_ssbd_mitigation(void)
@@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
return false;
}
+static inline enum ssbd_state get_sbdd_state(void)
+{
+ return ARM_SSBD_UNKNOWN;
+}
+
#endif
#endif /* __ARM_CPUERRATA_H__ */
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 650744d28b..a6804cec99 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -265,6 +265,7 @@ struct arm_smccc_res {
0x7FFF)
/* SMCCC error codes */
+#define ARM_SMCCC_NOT_REQUIRED (-2)
#define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
#define ARM_SMCCC_NOT_SUPPORTED (-1)
#define ARM_SMCCC_SUCCESS (0)
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-22 17:42 ` [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation Julien Grall
@ 2018-05-23 22:34 ` Stefano Stabellini
2018-05-24 0:48 ` Stefano Stabellini
2018-05-24 9:52 ` Julien Grall
2018-05-23 23:23 ` Stefano Stabellini
1 sibling, 2 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 22:34 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> useful to either permanently enable or disable the workaround for cases
> where the user decides that they'd rather not get a trap overhead, and
> keep the mitigation permanently on or off instead of switching it on
> exception entry/exit.
>
> In any case, default to mitigation being enabled.
>
> At the same time provide a accessor to know the state of the mitigation.
>
> SIgned-off-by: Julien Grall <julien.grall@arm.com>
> ---
> docs/misc/xen-command-line.markdown | 18 ++++++
> xen/arch/arm/cpuerrata.c | 115 ++++++++++++++++++++++++++++++++----
> xen/include/asm-arm/cpuerrata.h | 21 +++++++
> xen/include/asm-arm/smccc.h | 1 +
> 4 files changed, 144 insertions(+), 11 deletions(-)
>
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> index 8712a833a2..962028b6ed 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 670ms. Any number
> is being interpreted as a custom timeout in milliseconds. Zero or boolean
> false disable the quirk workaround, which is also the default.
>
> +### spec-ctrl (Arm)
> +> `= List of [ ssbd=force-disable|runtime|force-enable ]`
Why a list? Shouldn't it be one or the other?
> +Controls for speculative execution sidechannel mitigations.
> +
> +The option `ssbd=` is used to control the state of Speculative Store
> +Bypass Disable (SSBD) mitigation.
> +
> +* `ssbd=force-disable` will keep the mitigation permanently off. The guest
> +will not be able to control the state of the mitigation.
> +* `ssbd=runtime` will always turn on the mitigation when running in the
> +hypervisor context. The guest will be to turn on/off the mitigation for
> +itself by using the firmware interface ARCH\_WORKAROUND\_2.
> +* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
> +not be able to control the state of the mitigation.
> +
> +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> +
> ### spec-ctrl (x86)
> > `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
> > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}=<bool> ]`
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index bcea2eb6e5..f921721a66 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
>
> #ifdef CONFIG_ARM_SSBD
>
> +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
> +
> +static int __init parse_spec_ctrl(const char *s)
> +{
> + const char *ss;
> + int rc = 0;
> +
> + do {
> + ss = strchr(s, ',');
> + if ( !ss )
> + ss = strchr(s, '\0');
It doesn't look like it is necessary to parse ',' at all. I would remove
the while loop too.
> + if ( !strncmp(s, "ssbd=", 5) )
> + {
> + s += 5;
> +
> + if ( !strncmp(s, "force-disable", ss - s) )
> + ssbd_state = ARM_SSBD_FORCE_DISABLE;
> + else if ( !strncmp(s, "runtime", ss - s) )
> + ssbd_state = ARM_SSBD_RUNTIME;
> + else if ( !strncmp(s, "force-enable", ss - s) )
> + ssbd_state = ARM_SSBD_FORCE_ENABLE;
> + else
> + rc = -EINVAL;
> + }
> + else
> + rc = -EINVAL;
> +
> + s = ss + 1;
> + } while ( *ss );
> +
> + return rc;
> +}
> +custom_param("spec-ctrl", parse_spec_ctrl);
> +
> /*
> * Assembly code may use the variable directly, so we need to make sure
> * it fits in a register.
> @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
> static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> {
> struct arm_smccc_res res;
> - bool supported = true;
> + bool required = true;
Please avoid this renaming. Choose one name or the other from the start.
> if ( smccc_ver < SMCCC_VERSION(1, 1) )
> return false;
>
> - /*
> - * The probe function return value is either negative (unsupported
> - * or mitigated), positive (unaffected), or zero (requires
> - * mitigation). We only need to do anything in the last case.
> - */
I would keep the comment
> arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> - if ( (int)res.a0 != 0 )
> - supported = false;
>
> - if ( supported )
> - this_cpu(ssbd_callback_required) = 1;
> + switch ( (int)res.a0 )
Please introduce this switch in the previous patch. But it makes sense
to add the ssbd_state variable in this patch.
> + {
> + case ARM_SMCCC_NOT_SUPPORTED:
> + ssbd_state = ARM_SSBD_UNKNOWN;
> + return false;
> +
> + case ARM_SMCCC_NOT_REQUIRED:
> + ssbd_state = ARM_SSBD_MITIGATED;
> + return false;
> +
> + case ARM_SMCCC_SUCCESS:
> + required = true;
> + break;
> +
> + case 1: /* Mitigation not required on this CPU. */
> + required = false;
> + break;
This should "return false". Also, it might make sense to set ssbd_state
to ARM_SSBD_MITIGATED?
> +
> + default:
> + ASSERT_UNREACHABLE();
> + return false;
> + }
> +
> + switch ( ssbd_state )
> + {
> + case ARM_SSBD_FORCE_DISABLE:
> + {
> + static bool once = true;
> +
> + if ( once )
> + printk("%s disabled from command-line\n", entry->desc);
> + once = false;
> +
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> + required = false;
> +
> + break;
> + }
> +
> + case ARM_SSBD_RUNTIME:
> + if ( required )
> + {
> + this_cpu(ssbd_callback_required) = 1;
We have the ARM_SSBD bit, the ssbd_state variable and
ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
cores while ssbd_callback_required is per-cpu. Does
ssbd_callback_required really need to be per-cpu? Do we need both
variables? For instance, we could just return ssbd_state ==
ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> + }
> +
> + break;
> +
> + case ARM_SSBD_FORCE_ENABLE:
> + {
> + static bool once = true;
> +
> + if ( once )
> + printk("%s forced from command-line\n", entry->desc);
> + once = false;
> +
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> + required = true;
This function is supposed to detect whether a workaround is needed, not
enable it, right? Should this switch and relative code be moved to the
.enable function for this capability?
> + break;
> + }
> +
> + default:
> + ASSERT_UNREACHABLE();
> + return false;
> + }
>
> - return supported;
> + return required;
> }
> #endif
>
> @@ -371,6 +463,7 @@ static const struct arm_cpu_capabilities arm_errata[] = {
> #endif
> #ifdef CONFIG_ARM_SSBD
> {
> + .desc = "Speculative Store Bypass Disabled",
> .capability = ARM_SSBD,
> .matches = has_ssbd_mitigation,
> },
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index e628d3ff56..7fbb3dc0be 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
>
> #undef CHECK_WORKAROUND_HELPER
>
> +enum ssbd_state
> +{
> + ARM_SSBD_UNKNOWN,
> + ARM_SSBD_FORCE_DISABLE,
> + ARM_SSBD_RUNTIME,
> + ARM_SSBD_FORCE_ENABLE,
> + ARM_SSBD_MITIGATED,
> +};
> +
> #ifdef CONFIG_ARM_SSBD
>
> #include <asm/current.h>
>
> +extern enum ssbd_state ssbd_state;
> +
> +static inline enum ssbd_state get_ssbd_state(void)
> +{
> + return ssbd_state;
> +}
> +
> DECLARE_PER_CPU(register_t, ssbd_callback_required);
>
> static inline bool cpu_require_ssbd_mitigation(void)
> @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
> return false;
> }
>
> +static inline enum ssbd_state get_sbdd_state(void)
> +{
> + return ARM_SSBD_UNKNOWN;
> +}
> +
> #endif
>
> #endif /* __ARM_CPUERRATA_H__ */
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index 650744d28b..a6804cec99 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -265,6 +265,7 @@ struct arm_smccc_res {
> 0x7FFF)
>
> /* SMCCC error codes */
> +#define ARM_SMCCC_NOT_REQUIRED (-2)
> #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
> #define ARM_SMCCC_NOT_SUPPORTED (-1)
> #define ARM_SMCCC_SUCCESS (0)
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-23 22:34 ` Stefano Stabellini
@ 2018-05-24 0:48 ` Stefano Stabellini
2018-05-25 19:56 ` Julien Grall
2018-05-24 9:52 ` Julien Grall
1 sibling, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-24 0:48 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, Julien Grall, andre.przywara
On Wed, 23 May 2018, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
> > On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> > useful to either permanently enable or disable the workaround for cases
> > where the user decides that they'd rather not get a trap overhead, and
> > keep the mitigation permanently on or off instead of switching it on
> > exception entry/exit.
> >
> > In any case, default to mitigation being enabled.
> >
> > At the same time provide a accessor to know the state of the mitigation.
> >
> > SIgned-off-by: Julien Grall <julien.grall@arm.com>
> > ---
> > docs/misc/xen-command-line.markdown | 18 ++++++
> > xen/arch/arm/cpuerrata.c | 115 ++++++++++++++++++++++++++++++++----
> > xen/include/asm-arm/cpuerrata.h | 21 +++++++
> > xen/include/asm-arm/smccc.h | 1 +
> > 4 files changed, 144 insertions(+), 11 deletions(-)
> >
> > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> > index 8712a833a2..962028b6ed 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 670ms. Any number
> > is being interpreted as a custom timeout in milliseconds. Zero or boolean
> > false disable the quirk workaround, which is also the default.
> >
> > +### spec-ctrl (Arm)
> > +> `= List of [ ssbd=force-disable|runtime|force-enable ]`
>
> Why a list? Shouldn't it be one or the other?
>
> > +Controls for speculative execution sidechannel mitigations.
> > +
> > +The option `ssbd=` is used to control the state of Speculative Store
> > +Bypass Disable (SSBD) mitigation.
> > +
> > +* `ssbd=force-disable` will keep the mitigation permanently off. The guest
> > +will not be able to control the state of the mitigation.
> > +* `ssbd=runtime` will always turn on the mitigation when running in the
> > +hypervisor context. The guest will be to turn on/off the mitigation for
> > +itself by using the firmware interface ARCH\_WORKAROUND\_2.
> > +* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
> > +not be able to control the state of the mitigation.
> > +
> > +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> > +
> > ### spec-ctrl (x86)
> > > `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
> > > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}=<bool> ]`
> > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> > index bcea2eb6e5..f921721a66 100644
> > --- a/xen/arch/arm/cpuerrata.c
> > +++ b/xen/arch/arm/cpuerrata.c
> > @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
> >
> > #ifdef CONFIG_ARM_SSBD
> >
> > +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
> > +
> > +static int __init parse_spec_ctrl(const char *s)
> > +{
> > + const char *ss;
> > + int rc = 0;
> > +
> > + do {
> > + ss = strchr(s, ',');
> > + if ( !ss )
> > + ss = strchr(s, '\0');
>
> It doesn't look like it is necessary to parse ',' at all. I would remove
> the while loop too.
>
>
> > + if ( !strncmp(s, "ssbd=", 5) )
> > + {
> > + s += 5;
> > +
> > + if ( !strncmp(s, "force-disable", ss - s) )
> > + ssbd_state = ARM_SSBD_FORCE_DISABLE;
> > + else if ( !strncmp(s, "runtime", ss - s) )
> > + ssbd_state = ARM_SSBD_RUNTIME;
> > + else if ( !strncmp(s, "force-enable", ss - s) )
> > + ssbd_state = ARM_SSBD_FORCE_ENABLE;
> > + else
> > + rc = -EINVAL;
> > + }
> > + else
> > + rc = -EINVAL;
> > +
> > + s = ss + 1;
> > + } while ( *ss );
> > +
> > + return rc;
> > +}
> > +custom_param("spec-ctrl", parse_spec_ctrl);
> > +
> > /*
> > * Assembly code may use the variable directly, so we need to make sure
> > * it fits in a register.
> > @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
> > static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
> > {
> > struct arm_smccc_res res;
> > - bool supported = true;
> > + bool required = true;
>
> Please avoid this renaming. Choose one name or the other from the start.
>
>
> > if ( smccc_ver < SMCCC_VERSION(1, 1) )
> > return false;
> >
> > - /*
> > - * The probe function return value is either negative (unsupported
> > - * or mitigated), positive (unaffected), or zero (requires
> > - * mitigation). We only need to do anything in the last case.
> > - */
>
> I would keep the comment
>
>
> > arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> > ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> > - if ( (int)res.a0 != 0 )
> > - supported = false;
> >
> > - if ( supported )
> > - this_cpu(ssbd_callback_required) = 1;
> > + switch ( (int)res.a0 )
>
> Please introduce this switch in the previous patch. But it makes sense
> to add the ssbd_state variable in this patch.
>
>
> > + {
> > + case ARM_SMCCC_NOT_SUPPORTED:
> > + ssbd_state = ARM_SSBD_UNKNOWN;
> > + return false;
> > +
> > + case ARM_SMCCC_NOT_REQUIRED:
> > + ssbd_state = ARM_SSBD_MITIGATED;
> > + return false;
> > +
> > + case ARM_SMCCC_SUCCESS:
> > + required = true;
> > + break;
> > +
> > + case 1: /* Mitigation not required on this CPU. */
> > + required = false;
> > + break;
>
> This should "return false". Also, it might make sense to set ssbd_state
> to ARM_SSBD_MITIGATED?
>
>
> > +
> > + default:
> > + ASSERT_UNREACHABLE();
> > + return false;
> > + }
> > +
> > + switch ( ssbd_state )
> > + {
> > + case ARM_SSBD_FORCE_DISABLE:
> > + {
> > + static bool once = true;
> > +
> > + if ( once )
> > + printk("%s disabled from command-line\n", entry->desc);
> > + once = false;
> > +
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> > + required = false;
> > +
> > + break;
> > + }
> > +
> > + case ARM_SSBD_RUNTIME:
> > + if ( required )
> > + {
> > + this_cpu(ssbd_callback_required) = 1;
>
> We have the ARM_SSBD bit, the ssbd_state variable and
> ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
> cores while ssbd_callback_required is per-cpu. Does
> ssbd_callback_required really need to be per-cpu? Do we need both
> variables? For instance, we could just return ssbd_state ==
> ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
After reading the whole series, I think ssbd_state should be a per_cpu
variable. parse_spec_ctrl initializes ssbd_state to the same value on
all cpus. has_ssbd_mitigation modifies ssbd_state only on the CPUs it is
running on. We get rid of ssbd_callback_required. The assembly fast past
reads ssbd_state instead of ssbd_callback_required.
What do you think?
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > + }
> > +
> > + break;
> > +
> > + case ARM_SSBD_FORCE_ENABLE:
> > + {
> > + static bool once = true;
> > +
> > + if ( once )
> > + printk("%s forced from command-line\n", entry->desc);
> > + once = false;
> > +
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > + required = true;
>
> This function is supposed to detect whether a workaround is needed, not
> enable it, right? Should this switch and relative code be moved to the
> .enable function for this capability?
>
>
> > + break;
> > + }
> > +
> > + default:
> > + ASSERT_UNREACHABLE();
> > + return false;
> > + }
> >
> > - return supported;
> > + return required;
> > }
> > #endif
> >
> > @@ -371,6 +463,7 @@ static const struct arm_cpu_capabilities arm_errata[] = {
> > #endif
> > #ifdef CONFIG_ARM_SSBD
> > {
> > + .desc = "Speculative Store Bypass Disabled",
> > .capability = ARM_SSBD,
> > .matches = has_ssbd_mitigation,
> > },
> > diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> > index e628d3ff56..7fbb3dc0be 100644
> > --- a/xen/include/asm-arm/cpuerrata.h
> > +++ b/xen/include/asm-arm/cpuerrata.h
> > @@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
> >
> > #undef CHECK_WORKAROUND_HELPER
> >
> > +enum ssbd_state
> > +{
> > + ARM_SSBD_UNKNOWN,
> > + ARM_SSBD_FORCE_DISABLE,
> > + ARM_SSBD_RUNTIME,
> > + ARM_SSBD_FORCE_ENABLE,
> > + ARM_SSBD_MITIGATED,
> > +};
> > +
> > #ifdef CONFIG_ARM_SSBD
> >
> > #include <asm/current.h>
> >
> > +extern enum ssbd_state ssbd_state;
> > +
> > +static inline enum ssbd_state get_ssbd_state(void)
> > +{
> > + return ssbd_state;
> > +}
> > +
> > DECLARE_PER_CPU(register_t, ssbd_callback_required);
> >
> > static inline bool cpu_require_ssbd_mitigation(void)
> > @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
> > return false;
> > }
> >
> > +static inline enum ssbd_state get_sbdd_state(void)
> > +{
> > + return ARM_SSBD_UNKNOWN;
> > +}
> > +
> > #endif
> >
> > #endif /* __ARM_CPUERRATA_H__ */
> > diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> > index 650744d28b..a6804cec99 100644
> > --- a/xen/include/asm-arm/smccc.h
> > +++ b/xen/include/asm-arm/smccc.h
> > @@ -265,6 +265,7 @@ struct arm_smccc_res {
> > 0x7FFF)
> >
> > /* SMCCC error codes */
> > +#define ARM_SMCCC_NOT_REQUIRED (-2)
> > #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
> > #define ARM_SMCCC_NOT_SUPPORTED (-1)
> > #define ARM_SMCCC_SUCCESS (0)
> > --
> > 2.11.0
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-24 0:48 ` Stefano Stabellini
@ 2018-05-25 19:56 ` Julien Grall
0 siblings, 0 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-25 19:56 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 05/24/2018 01:48 AM, Stefano Stabellini wrote:
> On Wed, 23 May 2018, Stefano Stabellini wrote:
>> On Tue, 22 May 2018, Julien Grall wrote:
>>> +
>>> + default:
>>> + ASSERT_UNREACHABLE();
>>> + return false;
>>> + }
>>> +
>>> + switch ( ssbd_state )
>>> + {
>>> + case ARM_SSBD_FORCE_DISABLE:
>>> + {
>>> + static bool once = true;
>>> +
>>> + if ( once )
>>> + printk("%s disabled from command-line\n", entry->desc);
>>> + once = false;
>>> +
>>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
>>> + required = false;
>>> +
>>> + break;
>>> + }
>>> +
>>> + case ARM_SSBD_RUNTIME:
>>> + if ( required )
>>> + {
>>> + this_cpu(ssbd_callback_required) = 1;
>>
>> We have the ARM_SSBD bit, the ssbd_state variable and
>> ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
>> cores while ssbd_callback_required is per-cpu. Does
>> ssbd_callback_required really need to be per-cpu? Do we need both
>> variables? For instance, we could just return ssbd_state ==
>> ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
>
> After reading the whole series, I think ssbd_state should be a per_cpu
> variable. parse_spec_ctrl initializes ssbd_state to the same value on
> all cpus. has_ssbd_mitigation modifies ssbd_state only on the CPUs it is
> running on. We get rid of ssbd_callback_required. The assembly fast past
> reads ssbd_state instead of ssbd_callback_required.
>
> What do you think?
We need to keep the global ssbd_state around for the vsmc code as we
need to tell the guest what is the system-wide decision.
This is because a vCPU may move from a affected CPU to a non-affected
one. So we need to inform the same on every vCPU (i.e mitigated,
dynamic...).
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-23 22:34 ` Stefano Stabellini
2018-05-24 0:48 ` Stefano Stabellini
@ 2018-05-24 9:52 ` Julien Grall
2018-05-25 20:51 ` Stefano Stabellini
1 sibling, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-24 9:52 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 23/05/18 23:34, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> On a system where the firmware implements ARCH_WORKAROUND_2, it may be
>> useful to either permanently enable or disable the workaround for cases
>> where the user decides that they'd rather not get a trap overhead, and
>> keep the mitigation permanently on or off instead of switching it on
>> exception entry/exit.
>>
>> In any case, default to mitigation being enabled.
>>
>> At the same time provide a accessor to know the state of the mitigation.
>>
>> SIgned-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>> docs/misc/xen-command-line.markdown | 18 ++++++
>> xen/arch/arm/cpuerrata.c | 115 ++++++++++++++++++++++++++++++++----
>> xen/include/asm-arm/cpuerrata.h | 21 +++++++
>> xen/include/asm-arm/smccc.h | 1 +
>> 4 files changed, 144 insertions(+), 11 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
>> index 8712a833a2..962028b6ed 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of 670ms. Any number
>> is being interpreted as a custom timeout in milliseconds. Zero or boolean
>> false disable the quirk workaround, which is also the default.
>>
>> +### spec-ctrl (Arm)
>> +> `= List of [ ssbd=force-disable|runtime|force-enable ]`
>
> Why a list? Shouldn't it be one or the other?
Because I am thinking to extend it and add the possibility to disable
branch predictor hardening. So I decided to get the code and
documentation ready right now.
>
>> +Controls for speculative execution sidechannel mitigations.
>> +
>> +The option `ssbd=` is used to control the state of Speculative Store
>> +Bypass Disable (SSBD) mitigation.
>> +
>> +* `ssbd=force-disable` will keep the mitigation permanently off. The guest
>> +will not be able to control the state of the mitigation.
>> +* `ssbd=runtime` will always turn on the mitigation when running in the
>> +hypervisor context. The guest will be to turn on/off the mitigation for
>> +itself by using the firmware interface ARCH\_WORKAROUND\_2.
>> +* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
>> +not be able to control the state of the mitigation.
>> +
>> +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
>> +
>> ### spec-ctrl (x86)
>> > `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
>> > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}=<bool> ]`
>> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
>> index bcea2eb6e5..f921721a66 100644
>> --- a/xen/arch/arm/cpuerrata.c
>> +++ b/xen/arch/arm/cpuerrata.c
>> @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
>>
>> #ifdef CONFIG_ARM_SSBD
>>
>> +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
>> +
>> +static int __init parse_spec_ctrl(const char *s)
>> +{
>> + const char *ss;
>> + int rc = 0;
>> +
>> + do {
>> + ss = strchr(s, ',');
>> + if ( !ss )
>> + ss = strchr(s, '\0');
>
> It doesn't look like it is necessary to parse ',' at all. I would remove
> the while loop too.
It matters, you want to catch and warn user that the command line is not
valid. Imagine someone decide to add ",..." after. It also make easier
to integrate new option without reworking it.
>
>
>> + if ( !strncmp(s, "ssbd=", 5) )
>> + {
>> + s += 5;
>> +
>> + if ( !strncmp(s, "force-disable", ss - s) )
>> + ssbd_state = ARM_SSBD_FORCE_DISABLE;
>> + else if ( !strncmp(s, "runtime", ss - s) )
>> + ssbd_state = ARM_SSBD_RUNTIME;
>> + else if ( !strncmp(s, "force-enable", ss - s) )
>> + ssbd_state = ARM_SSBD_FORCE_ENABLE;
>> + else
>> + rc = -EINVAL;
>> + }
>> + else
>> + rc = -EINVAL;
>> +
>> + s = ss + 1;
>> + } while ( *ss );
>> +
>> + return rc;
>> +}
>> +custom_param("spec-ctrl", parse_spec_ctrl);
>> +
>> /*
>> * Assembly code may use the variable directly, so we need to make sure
>> * it fits in a register.
>> @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
>> static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
>> {
>> struct arm_smccc_res res;
>> - bool supported = true;
>> + bool required = true;
>
> Please avoid this renaming. Choose one name or the other from the start.
This is what happen when you want to split a series in a logical way.
The name "required" does not make sense with the previous patch. So the
renaming make sense here.
>
>
>> if ( smccc_ver < SMCCC_VERSION(1, 1) )
>> return false;
>>
>> - /*
>> - * The probe function return value is either negative (unsupported
>> - * or mitigated), positive (unaffected), or zero (requires
>> - * mitigation). We only need to do anything in the last case.
>> - */
>
> I would keep the comment
The comment is not correct after this patch. The may need to act
differently depending on the comment line. Regarding the values, the
switch is more explanatory than those 3 lines.
>
>
>> arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
>> ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
>> - if ( (int)res.a0 != 0 )
>> - supported = false;
>>
>> - if ( supported )
>> - this_cpu(ssbd_callback_required) = 1;
>> + switch ( (int)res.a0 )
>
> Please introduce this switch in the previous patch. But it makes sense
> to add the ssbd_state variable in this patch.
Well, that's not going to make the diff simpler here as the switch will
be different. So I would keep the patch like that.
>
>
>> + {
>> + case ARM_SMCCC_NOT_SUPPORTED:
>> + ssbd_state = ARM_SSBD_UNKNOWN;
>> + return false;
>> +
>> + case ARM_SMCCC_NOT_REQUIRED:
>> + ssbd_state = ARM_SSBD_MITIGATED;
>> + return false;
>> +
>> + case ARM_SMCCC_SUCCESS:
>> + required = true;
>> + break;
>> +
>> + case 1: /* Mitigation not required on this CPU. */
>> + required = false;
>> + break;
>
> This should "return false".
It is perfectly fine to continue as it is safe to execute
ARCH_WORKAROUND_2 on that CPU.
Also, it might make sense to set ssbd_state
> to ARM_SSBD_MITIGATED?
No, the mitigation is not required on *that* CPU. It does not mean it
will not be required for all CPUs. So it makes sense to not update
ssbd_state.
>
>
>> +
>> + default:
>> + ASSERT_UNREACHABLE();
>> + return false;
>> + }
>> +
>> + switch ( ssbd_state )
>> + {
>> + case ARM_SSBD_FORCE_DISABLE:
>> + {
>> + static bool once = true;
>> +
>> + if ( once )
>> + printk("%s disabled from command-line\n", entry->desc);
>> + once = false;
>> +
>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
>> + required = false;
>> +
>> + break;
>> + }
>> +
>> + case ARM_SSBD_RUNTIME:
>> + if ( required )
>> + {
>> + this_cpu(ssbd_callback_required) = 1;
>
> We have the ARM_SSBD bit, the ssbd_state variable and
> ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
> cores while ssbd_callback_required is per-cpu. Does
> ssbd_callback_required really need to be per-cpu? > Do we need both
> variables? For instance, we could just return ssbd_state ==
> ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
Let me start with because a guest vCPU may run on any pCPU, you always
have to tell the guest the mitigation is required for all vCPUs.
By default, Linux is calling the workaround at entry from EL0 to enable
it and at exit to EL0 to disable it. The workaround will first trap in
EL2 and then get forwarded to EL3.
You can imagine that the trap to EL2 and then EL3 has a cost. If the
workaround is not necessary, then you can reduce that cost by avoiding
to trap at EL3. As you can have a platform with heterogenous CPUs, you
need that workaround per-CPU.
The ARM_SSBD feature bit is useful in order to put shortcut in place
using alternative (see check_workaround_ssbd). So on platform where the
mitigation is not required, all the new code is nearly a NOP.
The ssbd_state is used in various place to know what is the global state
of the mitigation:
- To initialize the vCPU state for the mitigation
- To report the guest what is the state of the mitigation using SMCCC
So all those variables have a specific purposes and cannot really be
replaced by another way.
>
>
>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
>> + }
>> +
>> + break;
>> +
>> + case ARM_SSBD_FORCE_ENABLE:
>> + {
>> + static bool once = true;
>> +
>> + if ( once )
>> + printk("%s forced from command-line\n", entry->desc);
>> + once = false;
>> +
>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
>> + required = true;
>
> This function is supposed to detect whether a workaround is needed, not
> enable it, right? Should this switch and relative code be moved to the
> .enable function for this capability?
I had the split before but it is difficult to get a nice split between
.enable and .matches. So I decided to follow what Linux/KVM did and put
everything in has_.
>
>
>> + break;
>> + }
>> +
>> + default:
>> + ASSERT_UNREACHABLE();
>> + return false;
>> + }
>>
>> - return supported;
>> + return required;
>> }
>> #endif
>>
>> @@ -371,6 +463,7 @@ static const struct arm_cpu_capabilities arm_errata[] = {
>> #endif
>> #ifdef CONFIG_ARM_SSBD
>> {
>> + .desc = "Speculative Store Bypass Disabled",
>> .capability = ARM_SSBD,
>> .matches = has_ssbd_mitigation,
>> },
>> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
>> index e628d3ff56..7fbb3dc0be 100644
>> --- a/xen/include/asm-arm/cpuerrata.h
>> +++ b/xen/include/asm-arm/cpuerrata.h
>> @@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
>>
>> #undef CHECK_WORKAROUND_HELPER
>>
>> +enum ssbd_state
>> +{
>> + ARM_SSBD_UNKNOWN,
>> + ARM_SSBD_FORCE_DISABLE,
>> + ARM_SSBD_RUNTIME,
>> + ARM_SSBD_FORCE_ENABLE,
>> + ARM_SSBD_MITIGATED,
>> +};
>> +
>> #ifdef CONFIG_ARM_SSBD
>>
>> #include <asm/current.h>
>>
>> +extern enum ssbd_state ssbd_state;
>> +
>> +static inline enum ssbd_state get_ssbd_state(void)
>> +{
>> + return ssbd_state;
>> +}
>> +
>> DECLARE_PER_CPU(register_t, ssbd_callback_required);
>>
>> static inline bool cpu_require_ssbd_mitigation(void)
>> @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
>> return false;
>> }
>>
>> +static inline enum ssbd_state get_sbdd_state(void)
>> +{
>> + return ARM_SSBD_UNKNOWN;
>> +}
>> +
>> #endif
>>
>> #endif /* __ARM_CPUERRATA_H__ */
>> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
>> index 650744d28b..a6804cec99 100644
>> --- a/xen/include/asm-arm/smccc.h
>> +++ b/xen/include/asm-arm/smccc.h
>> @@ -265,6 +265,7 @@ struct arm_smccc_res {
>> 0x7FFF)
>>
>> /* SMCCC error codes */
>> +#define ARM_SMCCC_NOT_REQUIRED (-2)
>> #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
>> #define ARM_SMCCC_NOT_SUPPORTED (-1)
>> #define ARM_SMCCC_SUCCESS (0)
>> --
>> 2.11.0
>>
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-24 9:52 ` Julien Grall
@ 2018-05-25 20:51 ` Stefano Stabellini
2018-05-29 11:31 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 20:51 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 23/05/18 23:34, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> > > useful to either permanently enable or disable the workaround for cases
> > > where the user decides that they'd rather not get a trap overhead, and
> > > keep the mitigation permanently on or off instead of switching it on
> > > exception entry/exit.
> > >
> > > In any case, default to mitigation being enabled.
> > >
> > > At the same time provide a accessor to know the state of the mitigation.
> > >
> > > SIgned-off-by: Julien Grall <julien.grall@arm.com>
> > > ---
> > > docs/misc/xen-command-line.markdown | 18 ++++++
> > > xen/arch/arm/cpuerrata.c | 115
> > > ++++++++++++++++++++++++++++++++----
> > > xen/include/asm-arm/cpuerrata.h | 21 +++++++
> > > xen/include/asm-arm/smccc.h | 1 +
> > > 4 files changed, 144 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/docs/misc/xen-command-line.markdown
> > > b/docs/misc/xen-command-line.markdown
> > > index 8712a833a2..962028b6ed 100644
> > > --- a/docs/misc/xen-command-line.markdown
> > > +++ b/docs/misc/xen-command-line.markdown
> > > @@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary
> > > timeout of 670ms. Any number
> > > is being interpreted as a custom timeout in milliseconds. Zero or
> > > boolean
> > > false disable the quirk workaround, which is also the default.
> > > +### spec-ctrl (Arm)
> > > +> `= List of [ ssbd=force-disable|runtime|force-enable ]`
> >
> > Why a list? Shouldn't it be one or the other?
>
> Because I am thinking to extend it and add the possibility to disable branch
> predictor hardening. So I decided to get the code and documentation ready
> right now.
OK, maybe it would be good to explain this in the commit message but it
is not necessary.
> > > +Controls for speculative execution sidechannel mitigations.
> > > +
> > > +The option `ssbd=` is used to control the state of Speculative Store
> > > +Bypass Disable (SSBD) mitigation.
> > > +
> > > +* `ssbd=force-disable` will keep the mitigation permanently off. The
> > > guest
> > > +will not be able to control the state of the mitigation.
> > > +* `ssbd=runtime` will always turn on the mitigation when running in the
> > > +hypervisor context. The guest will be to turn on/off the mitigation for
> > > +itself by using the firmware interface ARCH\_WORKAROUND\_2.
> > > +* `ssbd=force-enable` will keep the mitigation permanently on. The guest
> > > will
> > > +not be able to control the state of the mitigation.
> > > +
> > > +By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
> > > +
> > > ### spec-ctrl (x86)
> > > > `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
> > > > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}=<bool>
> > > ]`
> > > diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> > > index bcea2eb6e5..f921721a66 100644
> > > --- a/xen/arch/arm/cpuerrata.c
> > > +++ b/xen/arch/arm/cpuerrata.c
> > > @@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
> > > #ifdef CONFIG_ARM_SSBD
> > > +enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
> > > +
> > > +static int __init parse_spec_ctrl(const char *s)
> > > +{
> > > + const char *ss;
> > > + int rc = 0;
> > > +
> > > + do {
> > > + ss = strchr(s, ',');
> > > + if ( !ss )
> > > + ss = strchr(s, '\0');
> >
> > It doesn't look like it is necessary to parse ',' at all. I would remove
> > the while loop too.
>
> It matters, you want to catch and warn user that the command line is not
> valid. Imagine someone decide to add ",..." after. It also make easier to
> integrate new option without reworking it.
All right, I re-read the whole loop and looks fine to me.
> >
> >
> > > + if ( !strncmp(s, "ssbd=", 5) )
> > > + {
> > > + s += 5;
> > > +
> > > + if ( !strncmp(s, "force-disable", ss - s) )
> > > + ssbd_state = ARM_SSBD_FORCE_DISABLE;
> > > + else if ( !strncmp(s, "runtime", ss - s) )
> > > + ssbd_state = ARM_SSBD_RUNTIME;
> > > + else if ( !strncmp(s, "force-enable", ss - s) )
> > > + ssbd_state = ARM_SSBD_FORCE_ENABLE;
> > > + else
> > > + rc = -EINVAL;
> > > + }
> > > + else
> > > + rc = -EINVAL;
> > > +
> > > + s = ss + 1;
> > > + } while ( *ss );
> > > +
> > > + return rc;
> > > +}
> > > +custom_param("spec-ctrl", parse_spec_ctrl);
> > > +
> > > /*
> > > * Assembly code may use the variable directly, so we need to make sure
> > > * it fits in a register.
> > > @@ -246,25 +281,82 @@ DEFINE_PER_CPU_READ_MOSTLY(register_t,
> > > ssbd_callback_required);
> > > static bool has_ssbd_mitigation(const struct arm_cpu_capabilities
> > > *entry)
> > > {
> > > struct arm_smccc_res res;
> > > - bool supported = true;
> > > + bool required = true;
> >
> > Please avoid this renaming. Choose one name or the other from the start.
>
> This is what happen when you want to split a series in a logical way. The name
> "required" does not make sense with the previous patch. So the renaming make
> sense here.
Why does "required" not make sense in the previous patch? I think it
would be fine.
In any case, I prefer that both of us spend time on useful stuff rather
than choosing which patch should set the variable name :-) So I am going
to drop this regardless.
> >
> >
> > > if ( smccc_ver < SMCCC_VERSION(1, 1) )
> > > return false;
> > > - /*
> > > - * The probe function return value is either negative (unsupported
> > > - * or mitigated), positive (unaffected), or zero (requires
> > > - * mitigation). We only need to do anything in the last case.
> > > - */
> >
> > I would keep the comment
>
> The comment is not correct after this patch. The may need to act differently
> depending on the comment line. Regarding the values, the switch is more
> explanatory than those 3 lines.
I see. You could keep the comment, removing "We only need to do anything
in the last case." Either way is OK.
> >
> >
> > > arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> > > ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> > > - if ( (int)res.a0 != 0 )
> > > - supported = false;
> > > - if ( supported )
> > > - this_cpu(ssbd_callback_required) = 1;
> > > + switch ( (int)res.a0 )
> >
> > Please introduce this switch in the previous patch. But it makes sense
> > to add the ssbd_state variable in this patch.
>
> Well, that's not going to make the diff simpler here as the switch will be
> different. So I would keep the patch like that.
The split is a bit iffy to me, but if you don't want to change it, I can
live with it anyway.
> >
> > > + {
> > > + case ARM_SMCCC_NOT_SUPPORTED:
> > > + ssbd_state = ARM_SSBD_UNKNOWN;
> > > + return false;
> > > +
> > > + case ARM_SMCCC_NOT_REQUIRED:
> > > + ssbd_state = ARM_SSBD_MITIGATED;
> > > + return false;
> > > +
> > > + case ARM_SMCCC_SUCCESS:
> > > + required = true;
> > > + break;
> > > +
> > > + case 1: /* Mitigation not required on this CPU. */
> > > + required = false;
> > > + break;
> >
> > This should "return false".
>
> It is perfectly fine to continue as it is safe to execute ARCH_WORKAROUND_2 on
> that CPU.
This is the case where mitigation is not required but issuing the SMCCC
is safe. Instead of returning immediately, we go through the next
switch:
1) if ARM_SSBD_FORCE_DISABLE, we make the SMCCC
2) if ARM_SSBD_RUNTIME, we do nothing
3) if ARM_SSBD_FORCE_ENABLE, we make the SMCCC
What is the desired outcome for this situation? Obviously, continuing for
case 2) is pointless, we might as well return immediately. For 1) and 3)
is the intention that the SMCCC will actually have an effect even if the
mitigation is not required?
> Also, it might make sense to set ssbd_state
> > to ARM_SSBD_MITIGATED?
>
> No, the mitigation is not required on *that* CPU. It does not mean it will not
> be required for all CPUs. So it makes sense to not update ssbd_state.
I understand now, and thanks for the clarification on the call as well.
> >
> >
> > > +
> > > + default:
> > > + ASSERT_UNREACHABLE();
> > > + return false;
> > > + }
> > > +
> > > + switch ( ssbd_state )
> > > + {
> > > + case ARM_SSBD_FORCE_DISABLE:
> > > + {
> > > + static bool once = true;
> > > +
> > > + if ( once )
> > > + printk("%s disabled from command-line\n", entry->desc);
> > > + once = false;
> > > +
> > > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> > > + required = false;
> > > +
> > > + break;
> > > + }
> > > +
> > > + case ARM_SSBD_RUNTIME:
> > > + if ( required )
> > > + {
> > > + this_cpu(ssbd_callback_required) = 1;
> >
> > We have the ARM_SSBD bit, the ssbd_state variable and
> > ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
> > cores while ssbd_callback_required is per-cpu. Does
> > ssbd_callback_required really need to be per-cpu? > Do we need both
> > variables? For instance, we could just return ssbd_state ==
> > ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
>
> Let me start with because a guest vCPU may run on any pCPU, you always have to
> tell the guest the mitigation is required for all vCPUs.
>
> By default, Linux is calling the workaround at entry from EL0 to enable it and
> at exit to EL0 to disable it. The workaround will first trap in EL2 and then
> get forwarded to EL3.
>
> You can imagine that the trap to EL2 and then EL3 has a cost. If the
> workaround is not necessary, then you can reduce that cost by avoiding to trap
> at EL3. As you can have a platform with heterogenous CPUs, you need that
> workaround per-CPU.
>
> The ARM_SSBD feature bit is useful in order to put shortcut in place using
> alternative (see check_workaround_ssbd). So on platform where the mitigation
> is not required, all the new code is nearly a NOP.
>
> The ssbd_state is used in various place to know what is the global state of
> the mitigation:
> - To initialize the vCPU state for the mitigation
> - To report the guest what is the state of the mitigation using SMCCC
>
> So all those variables have a specific purposes and cannot really be replaced
> by another way.
Good explanation. Please add something like this to one of the commit
messages. Please also consider the following suggestion.
Wouldn't it make sense to remove ssbd_callback_required and make
ssbd_state a per-cpu variable? The Xen command line option would remain
the same, global, but it would initialize the value of ssbd_state on all
cpus. Then, has_ssbd_mitigation would further modify ssbd_state on a
specific cpu to ARM_SSBD_UNKNOWN (if ARM_SMCCC_NOT_SUPPORTED),
ARM_SSBD_MITIGATED (if ARM_SMCCC_NOT_REQUIRED"), etc. In the common
case, the CPUs that need the workaround will have ssbd_state set to
ARM_SSBD_RUNTIME, and the others will have ARM_SSBD_UNKNOWN or
ARM_SSBD_MITIGATED, or maybe a new value ARM_SSBD_UNNECESSARY. It looks
like it would still be simple to check on ssbd_state from assembly as
well, it can still be done with one instruction, we just need to make
sure to assign integer values to the enum, such as:
ARM_SSBD_UNKNOWN = 0,
ARM_SSBD_FORCE_DISABLE = 1,
etc.
> > > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > > + }
> > > +
> > > + break;
> > > +
> > > + case ARM_SSBD_FORCE_ENABLE:
> > > + {
> > > + static bool once = true;
> > > +
> > > + if ( once )
> > > + printk("%s forced from command-line\n", entry->desc);
> > > + once = false;
> > > +
> > > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > > + required = true;
> >
> > This function is supposed to detect whether a workaround is needed, not
> > enable it, right? Should this switch and relative code be moved to the
> > .enable function for this capability?
>
> I had the split before but it is difficult to get a nice split between .enable
> and .matches. So I decided to follow what Linux/KVM did and put everything in
> has_.
All right. Please add a note about this in the commit message or the code.
> >
> > > + break;
> > > + }
> > > +
> > > + default:
> > > + ASSERT_UNREACHABLE();
> > > + return false;
> > > + }
> > > - return supported;
> > > + return required;
> > > }
> > > #endif
> > > @@ -371,6 +463,7 @@ static const struct arm_cpu_capabilities
> > > arm_errata[] = {
> > > #endif
> > > #ifdef CONFIG_ARM_SSBD
> > > {
> > > + .desc = "Speculative Store Bypass Disabled",
> > > .capability = ARM_SSBD,
> > > .matches = has_ssbd_mitigation,
> > > },
> > > diff --git a/xen/include/asm-arm/cpuerrata.h
> > > b/xen/include/asm-arm/cpuerrata.h
> > > index e628d3ff56..7fbb3dc0be 100644
> > > --- a/xen/include/asm-arm/cpuerrata.h
> > > +++ b/xen/include/asm-arm/cpuerrata.h
> > > @@ -31,10 +31,26 @@ CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD,
> > > CONFIG_ARM_SSBD)
> > > #undef CHECK_WORKAROUND_HELPER
> > > +enum ssbd_state
> > > +{
> > > + ARM_SSBD_UNKNOWN,
> > > + ARM_SSBD_FORCE_DISABLE,
> > > + ARM_SSBD_RUNTIME,
> > > + ARM_SSBD_FORCE_ENABLE,
> > > + ARM_SSBD_MITIGATED,
> > > +};
> > > +
> > > #ifdef CONFIG_ARM_SSBD
> > > #include <asm/current.h>
> > > +extern enum ssbd_state ssbd_state;
> > > +
> > > +static inline enum ssbd_state get_ssbd_state(void)
> > > +{
> > > + return ssbd_state;
> > > +}
> > > +
> > > DECLARE_PER_CPU(register_t, ssbd_callback_required);
> > > static inline bool cpu_require_ssbd_mitigation(void)
> > > @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
> > > return false;
> > > }
> > > +static inline enum ssbd_state get_sbdd_state(void)
> > > +{
> > > + return ARM_SSBD_UNKNOWN;
> > > +}
> > > +
> > > #endif
> > > #endif /* __ARM_CPUERRATA_H__ */
> > > diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> > > index 650744d28b..a6804cec99 100644
> > > --- a/xen/include/asm-arm/smccc.h
> > > +++ b/xen/include/asm-arm/smccc.h
> > > @@ -265,6 +265,7 @@ struct arm_smccc_res {
> > > 0x7FFF)
> > > /* SMCCC error codes */
> > > +#define ARM_SMCCC_NOT_REQUIRED (-2)
> > > #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1)
> > > #define ARM_SMCCC_NOT_SUPPORTED (-1)
> > > #define ARM_SMCCC_SUCCESS (0)
> > > --
> > > 2.11.0
> > >
>
> Cheers,
>
> --
> Julien Grall
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-25 20:51 ` Stefano Stabellini
@ 2018-05-29 11:31 ` Julien Grall
2018-05-29 22:34 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-29 11:31 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
On 25/05/18 21:51, Stefano Stabellini wrote:
> On Thu, 24 May 2018, Julien Grall wrote:
>> On 23/05/18 23:34, Stefano Stabellini wrote:
>>> On Tue, 22 May 2018, Julien Grall >>>> arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
>>>> ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
>>>> - if ( (int)res.a0 != 0 )
>>>> - supported = false;
>>>> - if ( supported )
>>>> - this_cpu(ssbd_callback_required) = 1;
>>>> + switch ( (int)res.a0 )
>>>
>>> Please introduce this switch in the previous patch. But it makes sense
>>> to add the ssbd_state variable in this patch.
>>
>> Well, that's not going to make the diff simpler here as the switch will be
>> different. So I would keep the patch like that.
>
> The split is a bit iffy to me, but if you don't want to change it, I can
> live with it anyway.
I don't think the other way will help. But I will do it.
>>>
>>>> + {
>>>> + case ARM_SMCCC_NOT_SUPPORTED:
>>>> + ssbd_state = ARM_SSBD_UNKNOWN;
>>>> + return false;
>>>> +
>>>> + case ARM_SMCCC_NOT_REQUIRED:
>>>> + ssbd_state = ARM_SSBD_MITIGATED;
>>>> + return false;
>>>> +
>>>> + case ARM_SMCCC_SUCCESS:
>>>> + required = true;
>>>> + break;
>>>> +
>>>> + case 1: /* Mitigation not required on this CPU. */
>>>> + required = false;
>>>> + break;
>>>
>>> This should "return false".
>>
>> It is perfectly fine to continue as it is safe to execute ARCH_WORKAROUND_2 on
>> that CPU.
>
> This is the case where mitigation is not required but issuing the SMCCC
> is safe. Instead of returning immediately, we go through the next
> switch:
>
> 1) if ARM_SSBD_FORCE_DISABLE, we make the SMCCC
> 2) if ARM_SSBD_RUNTIME, we do nothing
> 3) if ARM_SSBD_FORCE_ENABLE, we make the SMCCC
>
> What is the desired outcome for this situation? Obviously, continuing for
> case 2) is pointless, we might as well return immediately. For 1) and 3)
> is the intention that the SMCCC will actually have an effect even if the
> mitigation is not required?
While the SMCCC call in 1) and 3) will do nothing for those CPUs, you
will still print a warning message if the user choose to force
enable/disable the mitigation.
>>>
>>>
>>>> +
>>>> + default:
>>>> + ASSERT_UNREACHABLE();
>>>> + return false;
>>>> + }
>>>> +
>>>> + switch ( ssbd_state )
>>>> + {
>>>> + case ARM_SSBD_FORCE_DISABLE:
>>>> + {
>>>> + static bool once = true;
>>>> +
>>>> + if ( once )
>>>> + printk("%s disabled from command-line\n", entry->desc);
>>>> + once = false;
>>>> +
>>>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
>>>> + required = false;
>>>> +
>>>> + break;
>>>> + }
>>>> +
>>>> + case ARM_SSBD_RUNTIME:
>>>> + if ( required )
>>>> + {
>>>> + this_cpu(ssbd_callback_required) = 1;
>>>
>>> We have the ARM_SSBD bit, the ssbd_state variable and
>>> ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
>>> cores while ssbd_callback_required is per-cpu. Does
>>> ssbd_callback_required really need to be per-cpu? > Do we need both
>>> variables? For instance, we could just return ssbd_state ==
>>> ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
>>
>> Let me start with because a guest vCPU may run on any pCPU, you always have to
>> tell the guest the mitigation is required for all vCPUs.
>>
>> By default, Linux is calling the workaround at entry from EL0 to enable it and
>> at exit to EL0 to disable it. The workaround will first trap in EL2 and then
>> get forwarded to EL3.
>>
>> You can imagine that the trap to EL2 and then EL3 has a cost. If the
>> workaround is not necessary, then you can reduce that cost by avoiding to trap
>> at EL3. As you can have a platform with heterogenous CPUs, you need that
>> workaround per-CPU.
>>
>> The ARM_SSBD feature bit is useful in order to put shortcut in place using
>> alternative (see check_workaround_ssbd). So on platform where the mitigation
>> is not required, all the new code is nearly a NOP.
>>
>> The ssbd_state is used in various place to know what is the global state of
>> the mitigation:
>> - To initialize the vCPU state for the mitigation
>> - To report the guest what is the state of the mitigation using SMCCC
>>
>> So all those variables have a specific purposes and cannot really be replaced
>> by another way.
>
> Good explanation. Please add something like this to one of the commit
> messages. Please also consider the following suggestion.
>
> Wouldn't it make sense to remove ssbd_callback_required and make
> ssbd_state a per-cpu variable? The Xen command line option would remain
> the same, global, but it would initialize the value of ssbd_state on all
> cpus. Then, has_ssbd_mitigation would further modify ssbd_state on a
> specific cpu to ARM_SSBD_UNKNOWN (if ARM_SMCCC_NOT_SUPPORTED),
> ARM_SSBD_MITIGATED (if ARM_SMCCC_NOT_REQUIRED"), etc. In the common
> case, the CPUs that need the workaround will have ssbd_state set to
> ARM_SSBD_RUNTIME, and the others will have ARM_SSBD_UNKNOWN or
> ARM_SSBD_MITIGATED, or maybe a new value ARM_SSBD_UNNECESSARY. It looks
> like it would still be simple to check on ssbd_state from assembly as
> well, it can still be done with one instruction, we just need to make
> sure to assign integer values to the enum, such as:
>
> ARM_SSBD_UNKNOWN = 0,
> ARM_SSBD_FORCE_DISABLE = 1,
>
> etc.
As I said in my previous e-mail, we need to know the global state of the
mitigation. This is because a vCPU may move from a affected CPU to a
non-affected one. Therefore we need to inform the same on every vCPU
(i.e mitigated, dynamic...).
Your suggestion will just save 4 bytes but add more code to find out
what is the system-wide decision for the mitigation.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-29 11:31 ` Julien Grall
@ 2018-05-29 22:34 ` Stefano Stabellini
2018-05-30 10:39 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-29 22:34 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Tue, 29 May 2018, Julien Grall wrote:
> On 25/05/18 21:51, Stefano Stabellini wrote:
> > On Thu, 24 May 2018, Julien Grall wrote:
> > > On 23/05/18 23:34, Stefano Stabellini wrote:
> > > > On Tue, 22 May 2018, Julien Grall >>>>
> > > > arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> > > > > ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> > > > > - if ( (int)res.a0 != 0 )
> > > > > - supported = false;
> > > > > - if ( supported )
> > > > > - this_cpu(ssbd_callback_required) = 1;
> > > > > + switch ( (int)res.a0 )
> > > >
> > > > Please introduce this switch in the previous patch. But it makes sense
> > > > to add the ssbd_state variable in this patch.
> > >
> > > Well, that's not going to make the diff simpler here as the switch will be
> > > different. So I would keep the patch like that.
> >
> > The split is a bit iffy to me, but if you don't want to change it, I can
> > live with it anyway.
>
> I don't think the other way will help. But I will do it.
Thank you
> > > >
> > > > > + {
> > > > > + case ARM_SMCCC_NOT_SUPPORTED:
> > > > > + ssbd_state = ARM_SSBD_UNKNOWN;
> > > > > + return false;
> > > > > +
> > > > > + case ARM_SMCCC_NOT_REQUIRED:
> > > > > + ssbd_state = ARM_SSBD_MITIGATED;
> > > > > + return false;
> > > > > +
> > > > > + case ARM_SMCCC_SUCCESS:
> > > > > + required = true;
> > > > > + break;
> > > > > +
> > > > > + case 1: /* Mitigation not required on this CPU. */
> > > > > + required = false;
> > > > > + break;
> > > >
> > > > This should "return false".
> > >
> > > It is perfectly fine to continue as it is safe to execute
> > > ARCH_WORKAROUND_2 on
> > > that CPU.
> >
> > This is the case where mitigation is not required but issuing the SMCCC
> > is safe. Instead of returning immediately, we go through the next
> > switch:
> >
> > 1) if ARM_SSBD_FORCE_DISABLE, we make the SMCCC
> > 2) if ARM_SSBD_RUNTIME, we do nothing
> > 3) if ARM_SSBD_FORCE_ENABLE, we make the SMCCC
> >
> > What is the desired outcome for this situation? Obviously, continuing for
> > case 2) is pointless, we might as well return immediately. For 1) and 3)
> > is the intention that the SMCCC will actually have an effect even if the
> > mitigation is not required?
>
> While the SMCCC call in 1) and 3) will do nothing for those CPUs, you will
> still print a warning message if the user choose to force enable/disable the
> mitigation.
Printing warnings could be a good idea. However, I think we should do
the same thing for "1" and for "ARM_SMCCC_NOT_REQUIRED", and maybe even
for "ARM_SMCCC_NOT_SUPPORTED": printing warnings for all or for none.
I also noticed that if the first SMCCC returns "1" and we continue, in
case ssbd_state == ARM_SSBD_FORCE_ENABLE, "required" gets changed to
"true". Do we want to let the user force-enable the mitigation even
when it will do nothing? I am not really sure, probably not? In any case
I would prefer if we kept the same behavior across "1" and
"ARM_SMCCC_NOT_REQUIRED".
> > > >
> > > >
> > > > > +
> > > > > + default:
> > > > > + ASSERT_UNREACHABLE();
> > > > > + return false;
> > > > > + }
> > > > > +
> > > > > + switch ( ssbd_state )
> > > > > + {
> > > > > + case ARM_SSBD_FORCE_DISABLE:
> > > > > + {
> > > > > + static bool once = true;
> > > > > +
> > > > > + if ( once )
> > > > > + printk("%s disabled from command-line\n", entry->desc);
> > > > > + once = false;
> > > > > +
> > > > > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> > > > > + required = false;
> > > > > +
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + case ARM_SSBD_RUNTIME:
> > > > > + if ( required )
> > > > > + {
> > > > > + this_cpu(ssbd_callback_required) = 1;
> > > >
> > > > We have the ARM_SSBD bit, the ssbd_state variable and
> > > > ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
> > > > cores while ssbd_callback_required is per-cpu. Does
> > > > ssbd_callback_required really need to be per-cpu? > Do we need both
> > > > variables? For instance, we could just return ssbd_state ==
> > > > ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
> > >
> > > Let me start with because a guest vCPU may run on any pCPU, you always
> > > have to
> > > tell the guest the mitigation is required for all vCPUs.
> > >
> > > By default, Linux is calling the workaround at entry from EL0 to enable it
> > > and
> > > at exit to EL0 to disable it. The workaround will first trap in EL2 and
> > > then
> > > get forwarded to EL3.
> > >
> > > You can imagine that the trap to EL2 and then EL3 has a cost. If the
> > > workaround is not necessary, then you can reduce that cost by avoiding to
> > > trap
> > > at EL3. As you can have a platform with heterogenous CPUs, you need that
> > > workaround per-CPU.
> > >
> > > The ARM_SSBD feature bit is useful in order to put shortcut in place using
> > > alternative (see check_workaround_ssbd). So on platform where the
> > > mitigation
> > > is not required, all the new code is nearly a NOP.
> > >
> > > The ssbd_state is used in various place to know what is the global state
> > > of
> > > the mitigation:
> > > - To initialize the vCPU state for the mitigation
> > > - To report the guest what is the state of the mitigation using SMCCC
> > >
> > > So all those variables have a specific purposes and cannot really be
> > > replaced
> > > by another way.
> >
> > Good explanation. Please add something like this to one of the commit
> > messages. Please also consider the following suggestion.
> >
> > Wouldn't it make sense to remove ssbd_callback_required and make
> > ssbd_state a per-cpu variable? The Xen command line option would remain
> > the same, global, but it would initialize the value of ssbd_state on all
> > cpus. Then, has_ssbd_mitigation would further modify ssbd_state on a
> > specific cpu to ARM_SSBD_UNKNOWN (if ARM_SMCCC_NOT_SUPPORTED),
> > ARM_SSBD_MITIGATED (if ARM_SMCCC_NOT_REQUIRED"), etc. In the common
> > case, the CPUs that need the workaround will have ssbd_state set to
> > ARM_SSBD_RUNTIME, and the others will have ARM_SSBD_UNKNOWN or
> > ARM_SSBD_MITIGATED, or maybe a new value ARM_SSBD_UNNECESSARY. It looks
> > like it would still be simple to check on ssbd_state from assembly as
> > well, it can still be done with one instruction, we just need to make
> > sure to assign integer values to the enum, such as:
> > ARM_SSBD_UNKNOWN = 0,
> > ARM_SSBD_FORCE_DISABLE = 1,
> >
> > etc.
>
> As I said in my previous e-mail, we need to know the global state of the
> mitigation. This is because a vCPU may move from a affected CPU to a
> non-affected one. Therefore we need to inform the same on every vCPU (i.e
> mitigated, dynamic...).
All right, but if the SMCCC(ARM_SMCCC_ARCH_FEATURES_FID,
ARM_SMCCC_ARCH_WORKAROUND_2_FID) returns ARM_SMCCC_SUCCESS on cpu0 and
ARM_SMCCC_NOT_REQUIRED on cpu1, the result will be that ssbd_state is
set to ARM_SSBD_MITIGATED for all cpus. Which is not what we want?
It doesn't look like the vsmc would return the right value anymore.
One solution would be that has_ssbd_mitigation is not allowed to set
ssbd_state to ARM_SSBD_UNKNOWN or ARM_SSBD_MITIGATED if previously, or
afterwards, the SMCCC returns ARM_SMCCC_SUCCESS. In other words,
ARM_SMCCC_SUCCESS trumps any other return values.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-29 22:34 ` Stefano Stabellini
@ 2018-05-30 10:39 ` Julien Grall
2018-05-30 20:10 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-30 10:39 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
> On Tue, 29 May 2018, Julien Grall wrote:
>> On 25/05/18 21:51, Stefano Stabellini wrote:
>>> On Thu, 24 May 2018, Julien Grall wrote:
>>>> On 23/05/18 23:34, Stefano Stabellini wrote:
>>>>> On Tue, 22 May 2018, Julien Grall >>>>
>>>>> arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
>>>>>> ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
>>>>>> - if ( (int)res.a0 != 0 )
>>>>>> - supported = false;
>>>>>> - if ( supported )
>>>>>> - this_cpu(ssbd_callback_required) = 1;
>>>>>> + switch ( (int)res.a0 )
>>>>>
>>>>> Please introduce this switch in the previous patch. But it makes sense
>>>>> to add the ssbd_state variable in this patch.
>>>>
>>>> Well, that's not going to make the diff simpler here as the switch will be
>>>> different. So I would keep the patch like that.
>>>
>>> The split is a bit iffy to me, but if you don't want to change it, I can
>>> live with it anyway.
>>
>> I don't think the other way will help. But I will do it.
>
> Thank you
>
>
>>>>>
>>>>>> + {
>>>>>> + case ARM_SMCCC_NOT_SUPPORTED:
>>>>>> + ssbd_state = ARM_SSBD_UNKNOWN;
>>>>>> + return false;
>>>>>> +
>>>>>> + case ARM_SMCCC_NOT_REQUIRED:
>>>>>> + ssbd_state = ARM_SSBD_MITIGATED;
>>>>>> + return false;
>>>>>> +
>>>>>> + case ARM_SMCCC_SUCCESS:
>>>>>> + required = true;
>>>>>> + break;
>>>>>> +
>>>>>> + case 1: /* Mitigation not required on this CPU. */
>>>>>> + required = false;
>>>>>> + break;
>>>>>
>>>>> This should "return false".
>>>>
>>>> It is perfectly fine to continue as it is safe to execute
>>>> ARCH_WORKAROUND_2 on
>>>> that CPU.
>>>
>>> This is the case where mitigation is not required but issuing the SMCCC
>>> is safe. Instead of returning immediately, we go through the next
>>> switch:
>>>
>>> 1) if ARM_SSBD_FORCE_DISABLE, we make the SMCCC
>>> 2) if ARM_SSBD_RUNTIME, we do nothing
>>> 3) if ARM_SSBD_FORCE_ENABLE, we make the SMCCC
>>>
>>> What is the desired outcome for this situation? Obviously, continuing for
>>> case 2) is pointless, we might as well return immediately. For 1) and 3)
>>> is the intention that the SMCCC will actually have an effect even if the
>>> mitigation is not required?
>>
>> While the SMCCC call in 1) and 3) will do nothing for those CPUs, you will
>> still print a warning message if the user choose to force enable/disable the
>> mitigation.
>
> Printing warnings could be a good idea. However, I think we should do
> the same thing for "1" and for "ARM_SMCCC_NOT_REQUIRED", and maybe even
> for "ARM_SMCCC_NOT_SUPPORTED": printing warnings for all or for none.
>
> I also noticed that if the first SMCCC returns "1" and we continue, in
> case ssbd_state == ARM_SSBD_FORCE_ENABLE, "required" gets changed to
> "true". Do we want to let the user force-enable the mitigation even
> when it will do nothing? I am not really sure, probably not? In any case
> I would prefer if we kept the same behavior across "1" and
> "ARM_SMCCC_NOT_REQUIRED".
I don't think it is right ot expect the same behavior for "1"and
"ARM_SMCCC_NOT_REQUIRED". There are majors difference between those 2
and ARM_SMCCC_NOT_SUPPORTED.
From the spec ARM DEN 0070A section 2.2.5:
- If your firmware does not support the call, ARM_SMCCC_NOT_SUPPORTED
will be returned for *all* CPUs. This will happen on current firmwares.
- If your firmware has mitigation permanently disabled/enabled for
*all* CPUs, ARM_SMCCC_NOT_REQUIRED will be returned.
- If one of the CPUs in the platform require dynamic mitigation, the
call will return 0 for them. The others CPUs will return 1.
Printing a warning for the first two will likely scare the user because
it is going to be printed on most of the current platforms.
Printing a warning for the last one makes sense because you know that
one of the CPU may be affected. That CPU may be bring up later on. So
you offer a print in similar place in the logs whatever the platform is.
>
>
>>>>>
>>>>>
>>>>>> +
>>>>>> + default:
>>>>>> + ASSERT_UNREACHABLE();
>>>>>> + return false;
>>>>>> + }
>>>>>> +
>>>>>> + switch ( ssbd_state )
>>>>>> + {
>>>>>> + case ARM_SSBD_FORCE_DISABLE:
>>>>>> + {
>>>>>> + static bool once = true;
>>>>>> +
>>>>>> + if ( once )
>>>>>> + printk("%s disabled from command-line\n", entry->desc);
>>>>>> + once = false;
>>>>>> +
>>>>>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
>>>>>> + required = false;
>>>>>> +
>>>>>> + break;
>>>>>> + }
>>>>>> +
>>>>>> + case ARM_SSBD_RUNTIME:
>>>>>> + if ( required )
>>>>>> + {
>>>>>> + this_cpu(ssbd_callback_required) = 1;
>>>>>
>>>>> We have the ARM_SSBD bit, the ssbd_state variable and
>>>>> ssbd_callback_required. Both ARM_SSBD and ssbd_state are shared across
>>>>> cores while ssbd_callback_required is per-cpu. Does
>>>>> ssbd_callback_required really need to be per-cpu? > Do we need both
>>>>> variables? For instance, we could just return ssbd_state ==
>>>>> ARM_SSBD_RUNTIME instead of this_cpu(ssbd_callback_required)?
>>>>
>>>> Let me start with because a guest vCPU may run on any pCPU, you always
>>>> have to
>>>> tell the guest the mitigation is required for all vCPUs.
>>>>
>>>> By default, Linux is calling the workaround at entry from EL0 to enable it
>>>> and
>>>> at exit to EL0 to disable it. The workaround will first trap in EL2 and
>>>> then
>>>> get forwarded to EL3.
>>>>
>>>> You can imagine that the trap to EL2 and then EL3 has a cost. If the
>>>> workaround is not necessary, then you can reduce that cost by avoiding to
>>>> trap
>>>> at EL3. As you can have a platform with heterogenous CPUs, you need that
>>>> workaround per-CPU.
>>>>
>>>> The ARM_SSBD feature bit is useful in order to put shortcut in place using
>>>> alternative (see check_workaround_ssbd). So on platform where the
>>>> mitigation
>>>> is not required, all the new code is nearly a NOP.
>>>>
>>>> The ssbd_state is used in various place to know what is the global state
>>>> of
>>>> the mitigation:
>>>> - To initialize the vCPU state for the mitigation
>>>> - To report the guest what is the state of the mitigation using SMCCC
>>>>
>>>> So all those variables have a specific purposes and cannot really be
>>>> replaced
>>>> by another way.
>>>
>>> Good explanation. Please add something like this to one of the commit
>>> messages. Please also consider the following suggestion.
>>>
>>> Wouldn't it make sense to remove ssbd_callback_required and make
>>> ssbd_state a per-cpu variable? The Xen command line option would remain
>>> the same, global, but it would initialize the value of ssbd_state on all
>>> cpus. Then, has_ssbd_mitigation would further modify ssbd_state on a
>>> specific cpu to ARM_SSBD_UNKNOWN (if ARM_SMCCC_NOT_SUPPORTED),
>>> ARM_SSBD_MITIGATED (if ARM_SMCCC_NOT_REQUIRED"), etc. In the common
>>> case, the CPUs that need the workaround will have ssbd_state set to
>>> ARM_SSBD_RUNTIME, and the others will have ARM_SSBD_UNKNOWN or
>>> ARM_SSBD_MITIGATED, or maybe a new value ARM_SSBD_UNNECESSARY. It looks
>>> like it would still be simple to check on ssbd_state from assembly as
>>> well, it can still be done with one instruction, we just need to make
>>> sure to assign integer values to the enum, such as:
>>> ARM_SSBD_UNKNOWN = 0,
>>> ARM_SSBD_FORCE_DISABLE = 1,
>>>
>>> etc.
>>
>> As I said in my previous e-mail, we need to know the global state of the
>> mitigation. This is because a vCPU may move from a affected CPU to a
>> non-affected one. Therefore we need to inform the same on every vCPU (i.e
>> mitigated, dynamic...).
>
> All right, but if the SMCCC(ARM_SMCCC_ARCH_FEATURES_FID,
> ARM_SMCCC_ARCH_WORKAROUND_2_FID) returns ARM_SMCCC_SUCCESS on cpu0 and
> ARM_SMCCC_NOT_REQUIRED on cpu1, the result will be that ssbd_state is
> set to ARM_SSBD_MITIGATED for all cpus. Which is not what we want?
>
> It doesn't look like the vsmc would return the right value anymore.
>
> One solution would be that has_ssbd_mitigation is not allowed to set
> ssbd_state to ARM_SSBD_UNKNOWN or ARM_SSBD_MITIGATED if previously, or
> afterwards, the SMCCC returns ARM_SMCCC_SUCCESS. In other words,
> ARM_SMCCC_SUCCESS trumps any other return values.
There seem to be a misunderstanding of the spec. If
ARM_SMCCC_NOT_REQUIRED is returned on one CPU, it will also be returned
for all the others. It means that *all* CPUs have the mitigations
permanently enabled/disabled.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-30 10:39 ` Julien Grall
@ 2018-05-30 20:10 ` Stefano Stabellini
2018-05-31 10:34 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-30 20:10 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Wed, 30 May 2018, Julien Grall wrote:
> On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
> > On Tue, 29 May 2018, Julien Grall wrote:
> > > On 25/05/18 21:51, Stefano Stabellini wrote:
> > > > On Thu, 24 May 2018, Julien Grall wrote:
> > > > > On 23/05/18 23:34, Stefano Stabellini wrote:
> > > > > > On Tue, 22 May 2018, Julien Grall >>>>
> > > > > > arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> > > > > > > ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
> > > > > > > - if ( (int)res.a0 != 0 )
> > > > > > > - supported = false;
> > > > > > > - if ( supported )
> > > > > > > - this_cpu(ssbd_callback_required) = 1;
> > > > > > > + switch ( (int)res.a0 )
> > > > > >
> > > > > > Please introduce this switch in the previous patch. But it makes
> > > > > > sense
> > > > > > to add the ssbd_state variable in this patch.
> > > > >
> > > > > Well, that's not going to make the diff simpler here as the switch
> > > > > will be
> > > > > different. So I would keep the patch like that.
> > > >
> > > > The split is a bit iffy to me, but if you don't want to change it, I can
> > > > live with it anyway.
> > >
> > > I don't think the other way will help. But I will do it.
> >
> > Thank you
> >
> >
> > > > > >
> > > > > > > + {
> > > > > > > + case ARM_SMCCC_NOT_SUPPORTED:
> > > > > > > + ssbd_state = ARM_SSBD_UNKNOWN;
> > > > > > > + return false;
> > > > > > > +
> > > > > > > + case ARM_SMCCC_NOT_REQUIRED:
> > > > > > > + ssbd_state = ARM_SSBD_MITIGATED;
> > > > > > > + return false;
> > > > > > > +
> > > > > > > + case ARM_SMCCC_SUCCESS:
> > > > > > > + required = true;
> > > > > > > + break;
> > > > > > > +
> > > > > > > + case 1: /* Mitigation not required on this CPU. */
> > > > > > > + required = false;
> > > > > > > + break;
> > > > > >
> > > > > > This should "return false".
> > > > >
> > > > > It is perfectly fine to continue as it is safe to execute
> > > > > ARCH_WORKAROUND_2 on
> > > > > that CPU.
> > > >
> > > > This is the case where mitigation is not required but issuing the SMCCC
> > > > is safe. Instead of returning immediately, we go through the next
> > > > switch:
> > > >
> > > > 1) if ARM_SSBD_FORCE_DISABLE, we make the SMCCC
> > > > 2) if ARM_SSBD_RUNTIME, we do nothing
> > > > 3) if ARM_SSBD_FORCE_ENABLE, we make the SMCCC
> > > >
> > > > What is the desired outcome for this situation? Obviously, continuing
> > > > for
> > > > case 2) is pointless, we might as well return immediately. For 1) and 3)
> > > > is the intention that the SMCCC will actually have an effect even if the
> > > > mitigation is not required?
> > >
> > > While the SMCCC call in 1) and 3) will do nothing for those CPUs, you will
> > > still print a warning message if the user choose to force enable/disable
> > > the
> > > mitigation.
> >
> > Printing warnings could be a good idea. However, I think we should do
> > the same thing for "1" and for "ARM_SMCCC_NOT_REQUIRED", and maybe even
> > for "ARM_SMCCC_NOT_SUPPORTED": printing warnings for all or for none.
> >
> > I also noticed that if the first SMCCC returns "1" and we continue, in case
> > ssbd_state == ARM_SSBD_FORCE_ENABLE, "required" gets changed to
> > "true". Do we want to let the user force-enable the mitigation even
> > when it will do nothing? I am not really sure, probably not? In any case
> > I would prefer if we kept the same behavior across "1" and
> > "ARM_SMCCC_NOT_REQUIRED".
>
> I don't think it is right ot expect the same behavior for "1"and
> "ARM_SMCCC_NOT_REQUIRED". There are majors difference between those 2 and
> ARM_SMCCC_NOT_SUPPORTED.
>
> From the spec ARM DEN 0070A section 2.2.5:
> - If your firmware does not support the call, ARM_SMCCC_NOT_SUPPORTED
> will be returned for *all* CPUs. This will happen on current firmwares.
> - If your firmware has mitigation permanently disabled/enabled for
> *all* CPUs, ARM_SMCCC_NOT_REQUIRED will be returned.
> - If one of the CPUs in the platform require dynamic mitigation, the
> call will return 0 for them. The others CPUs will return 1.
>
> Printing a warning for the first two will likely scare the user because it is
> going to be printed on most of the current platforms.
>
> Printing a warning for the last one makes sense because you know that one of
> the CPU may be affected. That CPU may be bring up later on. So you offer a
> print in similar place in the logs whatever the platform is.
I should have read the spec more carefully, thanks for the pointer.
Sorry about that. Finally, these patches are starting to make sense :-)
All right. I can see why ssbd_state and ssbd_callback_required are
separate and their purpose. Aside from adding more info to the commit
message, I'll make a couple of different suggestions:
1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state ==
ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return
early in that case. This will help clarify the intended behavior and
mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some
cpus. This is just optional, I am fine either way.
2) Can we turn ssbd_callback_required from a this_cpu variable to a
single cpu bitmask? It is not great to introduce a new per-cpu varible
for just one bit. It would save space and make it easier to access from
assembly as a bitmask as it would remove the need for the ldr_this_cpu
macro. If I am wrong and the bitmask makes things more complicated
rather than simpler, then keep the code as is and just mention it in the
next version of the patch.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-30 20:10 ` Stefano Stabellini
@ 2018-05-31 10:34 ` Julien Grall
2018-05-31 20:58 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-31 10:34 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi,
On 30/05/18 21:10, Stefano Stabellini wrote:
> On Wed, 30 May 2018, Julien Grall wrote:
>> On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
>>> On Tue, 29 May 2018, Julien Grall wrote:
>>>> On 25/05/18 21:51, Stefano Stabellini wrote:
>>>>> On Thu, 24 May 2018, Julien Grall wrote:
>>>>>> On 23/05/18 23:34, Stefano Stabellini wrote:
>>>>>>> On Tue, 22 May 2018, Julien Grall >>>>
> I should have read the spec more carefully, thanks for the pointer.
> Sorry about that. Finally, these patches are starting to make sense :-)
>
> All right. I can see why ssbd_state and ssbd_callback_required are
> separate and their purpose. Aside from adding more info to the commit
> message, I'll make a couple of different suggestions:
>
> 1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state ==
> ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return
> early in that case. This will help clarify the intended behavior and
> mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some
> cpus. This is just optional, I am fine either way.
A vendor not able to do a simple return "ARM_SMCCC_NOT_SUPPORTED" in
their firmware are not worth to support it in Xen. Most likely, more
important bits of that firmware would be broken.
>
> 2) Can we turn ssbd_callback_required from a this_cpu variable to a
> single cpu bitmask? It is not great to introduce a new per-cpu varible
> for just one bit. It would save space and make it easier to access from
> assembly as a bitmask as it would remove the need for the ldr_this_cpu
> macro. If I am wrong and the bitmask makes things more complicated
> rather than simpler, then keep the code as is and just mention it in the
> next version of the patch.
I hope you are aware that this will only save 8 byte per-CPU. On most of
embedded platform you will have less than 16 CPUs. So you would save at
most 128 bytes (woah!). If you are that tight in memory, then there are
better place to reduce the footprint.
I am also not sure to understand the problem of having ldr_this_cpu
around. The macro is simple and in any case, you would still require at
least a load for the bitmask.
Feel free to suggest an assembly version for the bitmask.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-31 10:34 ` Julien Grall
@ 2018-05-31 20:58 ` Stefano Stabellini
2018-05-31 21:29 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-31 20:58 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Thu, 31 May 2018, Julien Grall wrote:
> Hi,
>
> On 30/05/18 21:10, Stefano Stabellini wrote:
> > On Wed, 30 May 2018, Julien Grall wrote:
> > > On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
> > > > On Tue, 29 May 2018, Julien Grall wrote:
> > > > > On 25/05/18 21:51, Stefano Stabellini wrote:
> > > > > > On Thu, 24 May 2018, Julien Grall wrote:
> > > > > > > On 23/05/18 23:34, Stefano Stabellini wrote:
> > > > > > > > On Tue, 22 May 2018, Julien Grall >>>>
> > I should have read the spec more carefully, thanks for the pointer.
> > Sorry about that. Finally, these patches are starting to make sense :-)
> >
> > All right. I can see why ssbd_state and ssbd_callback_required are
> > separate and their purpose. Aside from adding more info to the commit
> > message, I'll make a couple of different suggestions:
> >
> > 1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state ==
> > ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return
> > early in that case. This will help clarify the intended behavior and
> > mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some
> > cpus. This is just optional, I am fine either way.
> A vendor not able to do a simple return "ARM_SMCCC_NOT_SUPPORTED" in their
> firmware are not worth to support it in Xen. Most likely, more important bits
> of that firmware would be broken.
>
> >
> > 2) Can we turn ssbd_callback_required from a this_cpu variable to a
> > single cpu bitmask? It is not great to introduce a new per-cpu varible
> > for just one bit. It would save space and make it easier to access from
> > assembly as a bitmask as it would remove the need for the ldr_this_cpu
> > macro. If I am wrong and the bitmask makes things more complicated
> > rather than simpler, then keep the code as is and just mention it in the
> > next version of the patch.
>
> I hope you are aware that this will only save 8 byte per-CPU. On most of
> embedded platform you will have less than 16 CPUs. So you would save at most
> 128 bytes (woah!). If you are that tight in memory, then there are better
> place to reduce the footprint.
>
> I am also not sure to understand the problem of having ldr_this_cpu around.
> The macro is simple and in any case, you would still require at least a load
> for the bitmask.
>
> Feel free to suggest an assembly version for the bitmask.
OK, this is very simple, the first that came to mind, I am sure you can
improve it:
// 65 is the cpu number, in this example
MOV X1, #65
// X1 tells us which doubleword to consider
// X2 has the bit shift for right doubleword
// X3 is the shifted X2, we'll use it to check the bitmask
AND X2, X1, #(64-1)
LSR X1, X1, #3
MOV X3, #0x1
LSL X3, X3, X2
// we load the pointer to the bitmask in X4
LDR X4, =cpumask
// increase the pointer to point to the right doubleword
ADD X4, X4, X1
// load the doubleword
LDR X4, [X4]
// mask with X3, the result is in X1
AND X1, X4, X3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-31 20:58 ` Stefano Stabellini
@ 2018-05-31 21:29 ` Julien Grall
0 siblings, 0 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-31 21:29 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: andre.przywara, Julien Grall, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 4022 bytes --]
(sorry for the formatting)
On Thu, 31 May 2018, 22:00 Stefano Stabellini, <sstabellini@kernel.org>
wrote:
> On Thu, 31 May 2018, Julien Grall wrote:
> > Hi,
> >
> > On 30/05/18 21:10, Stefano Stabellini wrote:
> > > On Wed, 30 May 2018, Julien Grall wrote:
> > > > On 05/29/2018 11:34 PM, Stefano Stabellini wrote:
> > > > > On Tue, 29 May 2018, Julien Grall wrote:
> > > > > > On 25/05/18 21:51, Stefano Stabellini wrote:
> > > > > > > On Thu, 24 May 2018, Julien Grall wrote:
> > > > > > > > On 23/05/18 23:34, Stefano Stabellini wrote:
> > > > > > > > > On Tue, 22 May 2018, Julien Grall >>>>
> > > I should have read the spec more carefully, thanks for the pointer.
> > > Sorry about that. Finally, these patches are starting to make sense :-)
> > >
> > > All right. I can see why ssbd_state and ssbd_callback_required are
> > > separate and their purpose. Aside from adding more info to the commit
> > > message, I'll make a couple of different suggestions:
> > >
> > > 1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state ==
> > > ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return
>
> > > early in that case. This will help clarify the intended behavior and
> > > mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some
> > > cpus. This is just optional, I am fine either way.
> > A vendor not able to do a simple return "ARM_SMCCC_NOT_SUPPORTED" in
> their
> > firmware are not worth to support it in Xen. Most likely, more important
> bits
> > of that firmware would be broken.
> >
> > >
> > > 2) Can we turn ssbd_callback_required from a this_cpu variable to a
> > > single cpu bitmask? It is not great to introduce a new per-cpu varible
> > > for just one bit. It would save space and make it easier to access from
> > > assembly as a bitmask as it would remove the need for the ldr_this_cpu
> > > macro. If I am wrong and the bitmask makes things more complicated
> > > rather than simpler, then keep the code as is and just mention it in
> the
> > > next version of the patch.
> >
> > I hope you are aware that this will only save 8 byte per-CPU. On most of
> > embedded platform you will have less than 16 CPUs. So you would save at
> most
> > 128 bytes (woah!). If you are that tight in memory, then there are better
> > place to reduce the footprint.
> >
> > I am also not sure to understand the problem of having ldr_this_cpu
> around.
> > The macro is simple and in any case, you would still require at least a
> load
> > for the bitmask.
> >
> > Feel free to suggest an assembly version for the bitmask.
>
> OK, this is very simple, the first that came to mind, I am sure you can
> improve it:
>
> // 65 is the cpu number, in this example
> MOV X1, #65
>
> // X1 tells us which doubleword to consider
> // X2 has the bit shift for right doubleword
> // X3 is the shifted X2, we'll use it to check the bitmask
> AND X2, X1, #(64-1)
> LSR X1, X1, #3
> MOV X3, #0x1
> LSL X3, X3, X2
>
> // we load the pointer to the bitmask in X4
> LDR X4, =cpumask
> // increase the pointer to point to the right doubleword
> ADD X4, X4, X1
> // load the doubleword
> LDR X4, [X4]
> // mask with X3, the result is in X1
> AND X1, X4, X3
>
Well, because of the SMCC v1.1 convention, you can only use x0-x3. So x4 is
a no go.
You also cannot use x1 because it contains the enable/disable boolean.
Furthermore ldr_this_cpu is only 3 instructions. With your current
solution, you have 9 instructions.
Even optimized, I honestly doubt you will manage 3 instructions. This is
30% more instructions!
So you are maybe going to save few bytes in memory, but everytime you
execute the SMC you will lose some time. As this is happening at every
entry/exit from EL0, this will have a significant impact on your workload.
At this stage, I will keep with the percpu variable. That's the best
trade-off between performance and footprint.
Cheers,
[-- Attachment #1.2: Type: text/html, Size: 5014 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-22 17:42 ` [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation Julien Grall
2018-05-23 22:34 ` Stefano Stabellini
@ 2018-05-23 23:23 ` Stefano Stabellini
2018-05-24 9:53 ` Julien Grall
1 sibling, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 23:23 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> +extern enum ssbd_state ssbd_state;
> +
> +static inline enum ssbd_state get_ssbd_state(void)
> +{
> + return ssbd_state;
> +}
> +
> DECLARE_PER_CPU(register_t, ssbd_callback_required);
>
> static inline bool cpu_require_ssbd_mitigation(void)
> @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
> return false;
> }
>
> +static inline enum ssbd_state get_sbdd_state(void)
The function name is mispelled
> +{
> + return ARM_SSBD_UNKNOWN;
> +}
> +
> #endif
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
2018-05-23 23:23 ` Stefano Stabellini
@ 2018-05-24 9:53 ` Julien Grall
0 siblings, 0 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-24 9:53 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 24/05/18 00:23, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> +extern enum ssbd_state ssbd_state;
>> +
>> +static inline enum ssbd_state get_ssbd_state(void)
>> +{
>> + return ssbd_state;
>> +}
>> +
>> DECLARE_PER_CPU(register_t, ssbd_callback_required);
>>
>> static inline bool cpu_require_ssbd_mitigation(void)
>> @@ -49,6 +65,11 @@ static inline bool cpu_require_ssbd_mitigation(void)
>> return false;
>> }
>>
>> +static inline enum ssbd_state get_sbdd_state(void)
>
> The function name is mispelled
Good catch. I will update it.
Cheers,
>
>
>> +{
>> + return ARM_SSBD_UNKNOWN;
>> +}
>> +
>> #endif
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (4 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 23:24 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 07/13] xen/arm: Simplify alternative patching Julien Grall
` (7 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
state of the workaround per-vCPU. The field 'pad' in cpu_info is now
repurposed to store flags easily accessible in assembly.
As the hypervisor will always run with the workaround enabled, we may
need to enable (on guest exit) or disable (on guest entry) the
workaround.
A follow-up patch will add fastpath for the workaround for arm64 guests.
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/domain.c | 8 ++++++++
xen/arch/arm/traps.c | 20 ++++++++++++++++++++
xen/arch/arm/vsmc.c | 37 +++++++++++++++++++++++++++++++++++++
xen/include/asm-arm/current.h | 6 +++++-
4 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index e7b33e92fb..9168195a9c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -21,6 +21,7 @@
#include <xen/wait.h>
#include <asm/alternative.h>
+#include <asm/cpuerrata.h>
#include <asm/cpufeature.h>
#include <asm/current.h>
#include <asm/event.h>
@@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
if ( (rc = vcpu_vtimer_init(v)) != 0 )
goto fail;
+ /*
+ * The workaround 2 (i.e SSBD mitigation) is enabled by default if
+ * supported.
+ */
+ if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+ v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
+
return rc;
fail:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..020b0b8eef 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2011,10 +2011,23 @@ inject_abt:
inject_iabt_exception(regs, gva, hsr.len);
}
+static inline bool needs_ssbd_flip(struct vcpu *v)
+{
+ if ( !check_workaround_ssbd() )
+ return false;
+
+ return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
+ cpu_require_ssbd_mitigation());
+}
+
static void enter_hypervisor_head(struct cpu_user_regs *regs)
{
if ( guest_mode(regs) )
{
+ /* If the guest has disabled the workaround, bring it back on. */
+ if ( needs_ssbd_flip(current) )
+ arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+
/*
* If we pended a virtual abort, preserve it until it gets cleared.
* See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
@@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
*/
SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
+ /*
+ * The hypervisor runs with the workaround always present.
+ * If the guest wants it disabled, so be it...
+ */
+ if ( needs_ssbd_flip(current) )
+ arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+
return;
}
local_irq_enable();
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 40a80d5760..c4ccae6030 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
#include <xen/lib.h>
#include <xen/types.h>
#include <public/arch-arm/smccc.h>
+#include <asm/cpuerrata.h>
#include <asm/cpufeature.h>
#include <asm/monitor.h>
#include <asm/regs.h>
@@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
ret = 0;
break;
+ case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+ switch ( get_ssbd_state() )
+ {
+ case ARM_SSBD_UNKNOWN:
+ case ARM_SSBD_FORCE_DISABLE:
+ break;
+
+ case ARM_SSBD_RUNTIME:
+ ret = ARM_SMCCC_SUCCESS;
+ break;
+
+ case ARM_SSBD_FORCE_ENABLE:
+ case ARM_SSBD_MITIGATED:
+ ret = ARM_SMCCC_NOT_REQUIRED;
+ break;
+ }
+ break;
}
set_user_reg(regs, 0, ret);
@@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
/* No return value */
return true;
+
+ case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+ {
+ bool enable = (uint32_t)get_user_reg(regs, 1);
+
+ /*
+ * ARM_WORKAROUND_2_FID should only be called when mitigation
+ * state can be changed at runtime.
+ */
+ if ( unlikely(get_ssbd_state() != ARM_SSBD_RUNTIME) )
+ return true;
+
+ if ( enable )
+ get_cpu_info()->flags |= CPUINFO_WORKAROUND_2_FLAG;
+ else
+ get_cpu_info()->flags &= ~CPUINFO_WORKAROUND_2_FLAG;
+
+ return true;
+ }
}
return false;
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..f9819b34fc 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -7,6 +7,10 @@
#include <asm/percpu.h>
#include <asm/processor.h>
+/* Tell whether the guest vCPU enabled Workaround 2 (i.e variant 4) */
+#define CPUINFO_WORKAROUND_2_FLAG_SHIFT 0
+#define CPUINFO_WORKAROUND_2_FLAG (_AC(1, U) << CPUINFO_WORKAROUND_2_FLAG_SHIFT)
+
#ifndef __ASSEMBLY__
struct vcpu;
@@ -21,7 +25,7 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
struct cpu_info {
struct cpu_user_regs guest_cpu_user_regs;
unsigned long elr;
- unsigned int pad;
+ uint32_t flags;
};
static inline struct cpu_info *get_cpu_info(void)
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests
2018-05-22 17:42 ` [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests Julien Grall
@ 2018-05-23 23:24 ` Stefano Stabellini
2018-05-24 0:40 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 23:24 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
> state of the workaround per-vCPU. The field 'pad' in cpu_info is now
> repurposed to store flags easily accessible in assembly.
>
> As the hypervisor will always run with the workaround enabled, we may
> need to enable (on guest exit) or disable (on guest entry) the
> workaround.
>
> A follow-up patch will add fastpath for the workaround for arm64 guests.
>
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
> xen/arch/arm/domain.c | 8 ++++++++
> xen/arch/arm/traps.c | 20 ++++++++++++++++++++
> xen/arch/arm/vsmc.c | 37 +++++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/current.h | 6 +++++-
> 4 files changed, 70 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index e7b33e92fb..9168195a9c 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -21,6 +21,7 @@
> #include <xen/wait.h>
>
> #include <asm/alternative.h>
> +#include <asm/cpuerrata.h>
> #include <asm/cpufeature.h>
> #include <asm/current.h>
> #include <asm/event.h>
> @@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
> if ( (rc = vcpu_vtimer_init(v)) != 0 )
> goto fail;
>
> + /*
> + * The workaround 2 (i.e SSBD mitigation) is enabled by default if
> + * supported.
> + */
> + if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
> + v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
> +
> return rc;
>
> fail:
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5c18e918b0..020b0b8eef 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2011,10 +2011,23 @@ inject_abt:
> inject_iabt_exception(regs, gva, hsr.len);
> }
>
> +static inline bool needs_ssbd_flip(struct vcpu *v)
> +{
> + if ( !check_workaround_ssbd() )
> + return false;
Why not check on get_ssbd_state() == ARM_SSBD_RUNTIME? I am confused on
when is the right time to use the cpu capability check
(check_workaround_ssbd), when is the right time to call get_ssbd_state()
and when is the right time to call cpu_require_ssbd_mitigation().
> + return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
> + cpu_require_ssbd_mitigation());
It looks like this won't do as intended when v->arch.cpu_info->flags = 0
and cpu_require_ssbd_mitigation() returns false, am I right?
Maybe needs_ssbd_flip() should be implemented as follows:
return get_ssbd_state() == ARM_SSBD_RUNTIME &&
!(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
> +}
> +
> static void enter_hypervisor_head(struct cpu_user_regs *regs)
> {
> if ( guest_mode(regs) )
> {
> + /* If the guest has disabled the workaround, bring it back on. */
> + if ( needs_ssbd_flip(current) )
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> +
> /*
> * If we pended a virtual abort, preserve it until it gets cleared.
> * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
> @@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
> */
> SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
>
> + /*
> + * The hypervisor runs with the workaround always present.
> + * If the guest wants it disabled, so be it...
> + */
> + if ( needs_ssbd_flip(current) )
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> +
> return;
> }
> local_irq_enable();
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 40a80d5760..c4ccae6030 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -18,6 +18,7 @@
> #include <xen/lib.h>
> #include <xen/types.h>
> #include <public/arch-arm/smccc.h>
> +#include <asm/cpuerrata.h>
> #include <asm/cpufeature.h>
> #include <asm/monitor.h>
> #include <asm/regs.h>
> @@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
> if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
> ret = 0;
> break;
> + case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> + switch ( get_ssbd_state() )
> + {
> + case ARM_SSBD_UNKNOWN:
> + case ARM_SSBD_FORCE_DISABLE:
> + break;
> +
> + case ARM_SSBD_RUNTIME:
> + ret = ARM_SMCCC_SUCCESS;
> + break;
> +
> + case ARM_SSBD_FORCE_ENABLE:
> + case ARM_SSBD_MITIGATED:
> + ret = ARM_SMCCC_NOT_REQUIRED;
> + break;
> + }
> + break;
> }
>
> set_user_reg(regs, 0, ret);
> @@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
> case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
> /* No return value */
> return true;
> +
> + case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> + {
> + bool enable = (uint32_t)get_user_reg(regs, 1);
> +
> + /*
> + * ARM_WORKAROUND_2_FID should only be called when mitigation
> + * state can be changed at runtime.
> + */
> + if ( unlikely(get_ssbd_state() != ARM_SSBD_RUNTIME) )
> + return true;
> +
> + if ( enable )
> + get_cpu_info()->flags |= CPUINFO_WORKAROUND_2_FLAG;
> + else
> + get_cpu_info()->flags &= ~CPUINFO_WORKAROUND_2_FLAG;
> +
> + return true;
> + }
> }
>
> return false;
> diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
> index 7a0971fdea..f9819b34fc 100644
> --- a/xen/include/asm-arm/current.h
> +++ b/xen/include/asm-arm/current.h
> @@ -7,6 +7,10 @@
> #include <asm/percpu.h>
> #include <asm/processor.h>
>
> +/* Tell whether the guest vCPU enabled Workaround 2 (i.e variant 4) */
> +#define CPUINFO_WORKAROUND_2_FLAG_SHIFT 0
> +#define CPUINFO_WORKAROUND_2_FLAG (_AC(1, U) << CPUINFO_WORKAROUND_2_FLAG_SHIFT)
> +
> #ifndef __ASSEMBLY__
>
> struct vcpu;
> @@ -21,7 +25,7 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
> struct cpu_info {
> struct cpu_user_regs guest_cpu_user_regs;
> unsigned long elr;
> - unsigned int pad;
> + uint32_t flags;
> };
>
> static inline struct cpu_info *get_cpu_info(void)
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests
2018-05-23 23:24 ` Stefano Stabellini
@ 2018-05-24 0:40 ` Stefano Stabellini
2018-05-24 10:00 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-24 0:40 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, Julien Grall, andre.przywara
On Wed, 23 May 2018, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
> > In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
> > state of the workaround per-vCPU. The field 'pad' in cpu_info is now
> > repurposed to store flags easily accessible in assembly.
> >
> > As the hypervisor will always run with the workaround enabled, we may
> > need to enable (on guest exit) or disable (on guest entry) the
> > workaround.
> >
> > A follow-up patch will add fastpath for the workaround for arm64 guests.
> >
> > This is part of XSA-263.
> >
> > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > ---
> > xen/arch/arm/domain.c | 8 ++++++++
> > xen/arch/arm/traps.c | 20 ++++++++++++++++++++
> > xen/arch/arm/vsmc.c | 37 +++++++++++++++++++++++++++++++++++++
> > xen/include/asm-arm/current.h | 6 +++++-
> > 4 files changed, 70 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index e7b33e92fb..9168195a9c 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -21,6 +21,7 @@
> > #include <xen/wait.h>
> >
> > #include <asm/alternative.h>
> > +#include <asm/cpuerrata.h>
> > #include <asm/cpufeature.h>
> > #include <asm/current.h>
> > #include <asm/event.h>
> > @@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
> > if ( (rc = vcpu_vtimer_init(v)) != 0 )
> > goto fail;
> >
> > + /*
> > + * The workaround 2 (i.e SSBD mitigation) is enabled by default if
> > + * supported.
> > + */
> > + if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
> > + v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
> > +
> > return rc;
> >
> > fail:
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 5c18e918b0..020b0b8eef 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -2011,10 +2011,23 @@ inject_abt:
> > inject_iabt_exception(regs, gva, hsr.len);
> > }
> >
> > +static inline bool needs_ssbd_flip(struct vcpu *v)
> > +{
> > + if ( !check_workaround_ssbd() )
> > + return false;
>
> Why not check on get_ssbd_state() == ARM_SSBD_RUNTIME? I am confused on
> when is the right time to use the cpu capability check
> (check_workaround_ssbd), when is the right time to call get_ssbd_state()
> and when is the right time to call cpu_require_ssbd_mitigation().
>
>
> > + return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
> > + cpu_require_ssbd_mitigation());
>
> It looks like this won't do as intended when v->arch.cpu_info->flags = 0
> and cpu_require_ssbd_mitigation() returns false, am I right?
>
> Maybe needs_ssbd_flip() should be implemented as follows:
>
> return get_ssbd_state() == ARM_SSBD_RUNTIME &&
> !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
With the intention of supporting systems where not all CPUs need/have
the workaround, then it should be:
return cpu_require_ssbd_mitigation() &&
!(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
> > +}
> > +
> > static void enter_hypervisor_head(struct cpu_user_regs *regs)
> > {
> > if ( guest_mode(regs) )
> > {
> > + /* If the guest has disabled the workaround, bring it back on. */
> > + if ( needs_ssbd_flip(current) )
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > +
> > /*
> > * If we pended a virtual abort, preserve it until it gets cleared.
> > * See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
> > @@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
> > */
> > SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
> >
> > + /*
> > + * The hypervisor runs with the workaround always present.
> > + * If the guest wants it disabled, so be it...
> > + */
> > + if ( needs_ssbd_flip(current) )
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
> > +
> > return;
> > }
> > local_irq_enable();
> > diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> > index 40a80d5760..c4ccae6030 100644
> > --- a/xen/arch/arm/vsmc.c
> > +++ b/xen/arch/arm/vsmc.c
> > @@ -18,6 +18,7 @@
> > #include <xen/lib.h>
> > #include <xen/types.h>
> > #include <public/arch-arm/smccc.h>
> > +#include <asm/cpuerrata.h>
> > #include <asm/cpufeature.h>
> > #include <asm/monitor.h>
> > #include <asm/regs.h>
> > @@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
> > if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
> > ret = 0;
> > break;
> > + case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> > + switch ( get_ssbd_state() )
> > + {
> > + case ARM_SSBD_UNKNOWN:
> > + case ARM_SSBD_FORCE_DISABLE:
> > + break;
> > +
> > + case ARM_SSBD_RUNTIME:
> > + ret = ARM_SMCCC_SUCCESS;
> > + break;
> > +
> > + case ARM_SSBD_FORCE_ENABLE:
> > + case ARM_SSBD_MITIGATED:
> > + ret = ARM_SMCCC_NOT_REQUIRED;
> > + break;
> > + }
> > + break;
> > }
> >
> > set_user_reg(regs, 0, ret);
> > @@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
> > case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
> > /* No return value */
> > return true;
> > +
> > + case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
> > + {
> > + bool enable = (uint32_t)get_user_reg(regs, 1);
> > +
> > + /*
> > + * ARM_WORKAROUND_2_FID should only be called when mitigation
> > + * state can be changed at runtime.
> > + */
> > + if ( unlikely(get_ssbd_state() != ARM_SSBD_RUNTIME) )
> > + return true;
> > +
> > + if ( enable )
> > + get_cpu_info()->flags |= CPUINFO_WORKAROUND_2_FLAG;
> > + else
> > + get_cpu_info()->flags &= ~CPUINFO_WORKAROUND_2_FLAG;
> > +
> > + return true;
> > + }
> > }
> >
> > return false;
> > diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
> > index 7a0971fdea..f9819b34fc 100644
> > --- a/xen/include/asm-arm/current.h
> > +++ b/xen/include/asm-arm/current.h
> > @@ -7,6 +7,10 @@
> > #include <asm/percpu.h>
> > #include <asm/processor.h>
> >
> > +/* Tell whether the guest vCPU enabled Workaround 2 (i.e variant 4) */
> > +#define CPUINFO_WORKAROUND_2_FLAG_SHIFT 0
> > +#define CPUINFO_WORKAROUND_2_FLAG (_AC(1, U) << CPUINFO_WORKAROUND_2_FLAG_SHIFT)
> > +
> > #ifndef __ASSEMBLY__
> >
> > struct vcpu;
> > @@ -21,7 +25,7 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
> > struct cpu_info {
> > struct cpu_user_regs guest_cpu_user_regs;
> > unsigned long elr;
> > - unsigned int pad;
> > + uint32_t flags;
> > };
> >
> > static inline struct cpu_info *get_cpu_info(void)
> > --
> > 2.11.0
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests
2018-05-24 0:40 ` Stefano Stabellini
@ 2018-05-24 10:00 ` Julien Grall
2018-05-25 20:51 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-24 10:00 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 24/05/18 01:40, Stefano Stabellini wrote:
> On Wed, 23 May 2018, Stefano Stabellini wrote:
>> On Tue, 22 May 2018, Julien Grall wrote:
>>> In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
>>> state of the workaround per-vCPU. The field 'pad' in cpu_info is now
>>> repurposed to store flags easily accessible in assembly.
>>>
>>> As the hypervisor will always run with the workaround enabled, we may
>>> need to enable (on guest exit) or disable (on guest entry) the
>>> workaround.
>>>
>>> A follow-up patch will add fastpath for the workaround for arm64 guests.
>>>
>>> This is part of XSA-263.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>> ---
>>> xen/arch/arm/domain.c | 8 ++++++++
>>> xen/arch/arm/traps.c | 20 ++++++++++++++++++++
>>> xen/arch/arm/vsmc.c | 37 +++++++++++++++++++++++++++++++++++++
>>> xen/include/asm-arm/current.h | 6 +++++-
>>> 4 files changed, 70 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index e7b33e92fb..9168195a9c 100644
>>> --- a/xen/arch/arm/domain.c
>>> +++ b/xen/arch/arm/domain.c
>>> @@ -21,6 +21,7 @@
>>> #include <xen/wait.h>
>>>
>>> #include <asm/alternative.h>
>>> +#include <asm/cpuerrata.h>
>>> #include <asm/cpufeature.h>
>>> #include <asm/current.h>
>>> #include <asm/event.h>
>>> @@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
>>> if ( (rc = vcpu_vtimer_init(v)) != 0 )
>>> goto fail;
>>>
>>> + /*
>>> + * The workaround 2 (i.e SSBD mitigation) is enabled by default if
>>> + * supported.
>>> + */
>>> + if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
>>> + v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
>>> +
>>> return rc;
>>>
>>> fail:
>>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>>> index 5c18e918b0..020b0b8eef 100644
>>> --- a/xen/arch/arm/traps.c
>>> +++ b/xen/arch/arm/traps.c
>>> @@ -2011,10 +2011,23 @@ inject_abt:
>>> inject_iabt_exception(regs, gva, hsr.len);
>>> }
>>>
>>> +static inline bool needs_ssbd_flip(struct vcpu *v)
>>> +{
>>> + if ( !check_workaround_ssbd() )
>>> + return false;
>>
>> Why not check on get_ssbd_state() == ARM_SSBD_RUNTIME?
get_ssbd_state() would introduce an overhead for each entry/exit even on
platform not affected. check_workaround_ssbd() remove this overhead by
using an alternative.
> I am confused on
>> when is the right time to use the cpu capability check
>> (check_workaround_ssbd), when is the right time to call get_ssbd_state()
>> and when is the right time to call cpu_require_ssbd_mitigation().
See my answer in the previous patches.
>>
>>
>>> + return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
>>> + cpu_require_ssbd_mitigation());
>>
>> It looks like this won't do as intended when v->arch.cpu_info->flags = 0
>> and cpu_require_ssbd_mitigation() returns false, am I right?
>>
>> Maybe needs_ssbd_flip() should be implemented as follows:
>>
>> return get_ssbd_state() == ARM_SSBD_RUNTIME &&
>> !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
>
> With the intention of supporting systems where not all CPUs need/have
> the workaround, then it should be:
>
> return cpu_require_ssbd_mitigation() &&
> !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
Yes, I did the exact same error I reported to Marc on the KVM side :/. I
will update the patch.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests
2018-05-24 10:00 ` Julien Grall
@ 2018-05-25 20:51 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 20:51 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 24/05/18 01:40, Stefano Stabellini wrote:
> > On Wed, 23 May 2018, Stefano Stabellini wrote:
> > > On Tue, 22 May 2018, Julien Grall wrote:
> > > > In order to offer ARCH_WORKAROUND_2 support to guests, we need to track
> > > > the
> > > > state of the workaround per-vCPU. The field 'pad' in cpu_info is now
> > > > repurposed to store flags easily accessible in assembly.
> > > >
> > > > As the hypervisor will always run with the workaround enabled, we may
> > > > need to enable (on guest exit) or disable (on guest entry) the
> > > > workaround.
> > > >
> > > > A follow-up patch will add fastpath for the workaround for arm64 guests.
> > > >
> > > > This is part of XSA-263.
> > > >
> > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > ---
> > > > xen/arch/arm/domain.c | 8 ++++++++
> > > > xen/arch/arm/traps.c | 20 ++++++++++++++++++++
> > > > xen/arch/arm/vsmc.c | 37
> > > > +++++++++++++++++++++++++++++++++++++
> > > > xen/include/asm-arm/current.h | 6 +++++-
> > > > 4 files changed, 70 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > > > index e7b33e92fb..9168195a9c 100644
> > > > --- a/xen/arch/arm/domain.c
> > > > +++ b/xen/arch/arm/domain.c
> > > > @@ -21,6 +21,7 @@
> > > > #include <xen/wait.h>
> > > > #include <asm/alternative.h>
> > > > +#include <asm/cpuerrata.h>
> > > > #include <asm/cpufeature.h>
> > > > #include <asm/current.h>
> > > > #include <asm/event.h>
> > > > @@ -575,6 +576,13 @@ int vcpu_initialise(struct vcpu *v)
> > > > if ( (rc = vcpu_vtimer_init(v)) != 0 )
> > > > goto fail;
> > > > + /*
> > > > + * The workaround 2 (i.e SSBD mitigation) is enabled by default if
> > > > + * supported.
> > > > + */
> > > > + if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
> > > > + v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
> > > > +
> > > > return rc;
> > > > fail:
> > > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > > index 5c18e918b0..020b0b8eef 100644
> > > > --- a/xen/arch/arm/traps.c
> > > > +++ b/xen/arch/arm/traps.c
> > > > @@ -2011,10 +2011,23 @@ inject_abt:
> > > > inject_iabt_exception(regs, gva, hsr.len);
> > > > }
> > > > +static inline bool needs_ssbd_flip(struct vcpu *v)
> > > > +{
> > > > + if ( !check_workaround_ssbd() )
> > > > + return false;
> > >
> > > Why not check on get_ssbd_state() == ARM_SSBD_RUNTIME?
>
> get_ssbd_state() would introduce an overhead for each entry/exit even on
> platform not affected. check_workaround_ssbd() remove this overhead by using
> an alternative.
Ah yes, great idea.
> > I am confused on
> > > when is the right time to use the cpu capability check
> > > (check_workaround_ssbd), when is the right time to call get_ssbd_state()
> > > and when is the right time to call cpu_require_ssbd_mitigation().
>
> See my answer in the previous patches.
I understand now, I didn't realize we wanted to go into the details of
improving big.LITTLE scenarios with different erratas on the differnt
CPUs.
> > >
> > >
> > > > + return !((v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
> > > > + cpu_require_ssbd_mitigation());
> > >
> > > It looks like this won't do as intended when v->arch.cpu_info->flags = 0
> > > and cpu_require_ssbd_mitigation() returns false, am I right?
> > >
> > > Maybe needs_ssbd_flip() should be implemented as follows:
> > >
> > > return get_ssbd_state() == ARM_SSBD_RUNTIME &&
> > > !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
> >
> > With the intention of supporting systems where not all CPUs need/have
> > the workaround, then it should be:
> >
> > return cpu_require_ssbd_mitigation() &&
> > !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG)
>
> Yes, I did the exact same error I reported to Marc on the KVM side :/. I will
> update the patch.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 07/13] xen/arm: Simplify alternative patching
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (5 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-25 20:52 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature Julien Grall
` (6 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
I am aware of the missing commit message here. I wanted to send the
series on the ML to get some feedback first.
---
xen/arch/arm/alternative.c | 35 +++++++++++++----------------------
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 9ffdc475d6..bd62183def 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
/*
* The region patched should be read-write to allow __apply_alternatives
* to replacing the instructions when necessary.
+ *
+ * @update_offset: Offset between the region patched and the writable
+ * region for the update. 0 if the patched region is writable.
*/
-static int __apply_alternatives(const struct alt_region *region)
+static int __apply_alternatives(const struct alt_region *region,
+ paddr_t update_offset)
{
const struct alt_instr *alt;
- const u32 *replptr;
- u32 *origptr;
+ const u32 *replptr, *origptr;
+ u32 *updptr;
printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
@@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region *region)
BUG_ON(alt->alt_len != alt->orig_len);
origptr = ALT_ORIG_PTR(alt);
+ updptr = (void *)origptr + update_offset;
replptr = ALT_REPL_PTR(alt);
nr_inst = alt->alt_len / sizeof(insn);
@@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region *region)
for ( i = 0; i < nr_inst; i++ )
{
insn = get_alt_insn(alt, origptr + i, replptr + i);
- *(origptr + i) = cpu_to_le32(insn);
+ *(updptr + i) = cpu_to_le32(insn);
}
/* Ensure the new instructions reached the memory and nuke */
@@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
paddr_t xen_size = _end - _start;
unsigned int xen_order = get_order_from_bytes(xen_size);
void *xenmap;
- struct virtual_region patch_region = {
- .list = LIST_HEAD_INIT(patch_region.list),
- };
BUG_ON(patched);
@@ -178,30 +180,19 @@ static int __apply_alternatives_multi_stop(void *unused)
BUG_ON(!xenmap);
/*
- * If we generate a new branch instruction, the target will be
- * calculated in this re-mapped Xen region. So we have to register
- * this re-mapped Xen region as a virtual region temporarily.
- */
- patch_region.start = xenmap;
- patch_region.end = xenmap + xen_size;
- register_virtual_region(&patch_region);
-
- /*
* Find the virtual address of the alternative region in the new
* mapping.
* alt_instr contains relative offset, so the function
* __apply_alternatives will patch in the re-mapped version of
* Xen.
*/
- region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
- region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
+ region.begin = __alt_instructions;
+ region.end = __alt_instructions_end;
- ret = __apply_alternatives(®ion);
+ ret = __apply_alternatives(®ion, xenmap - (void *)_start);
/* The patching is not expected to fail during boot. */
BUG_ON(ret != 0);
- unregister_virtual_region(&patch_region);
-
vunmap(xenmap);
/* Barriers provided by the cache flushing */
@@ -235,7 +226,7 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
.end = end,
};
- return __apply_alternatives(®ion);
+ return __apply_alternatives(®ion, 0);
}
/*
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 07/13] xen/arm: Simplify alternative patching
2018-05-22 17:42 ` [PATCH 07/13] xen/arm: Simplify alternative patching Julien Grall
@ 2018-05-25 20:52 ` Stefano Stabellini
2018-05-25 21:34 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 20:52 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
You might want to CC Konrad next time on this patch
On Tue, 22 May 2018, Julien Grall wrote:
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> ---
> I am aware of the missing commit message here. I wanted to send the
> series on the ML to get some feedback first.
> ---
> xen/arch/arm/alternative.c | 35 +++++++++++++----------------------
> 1 file changed, 13 insertions(+), 22 deletions(-)
>
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> index 9ffdc475d6..bd62183def 100644
> --- a/xen/arch/arm/alternative.c
> +++ b/xen/arch/arm/alternative.c
> @@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
> /*
> * The region patched should be read-write to allow __apply_alternatives
> * to replacing the instructions when necessary.
> + *
> + * @update_offset: Offset between the region patched and the writable
> + * region for the update. 0 if the patched region is writable.
> */
> -static int __apply_alternatives(const struct alt_region *region)
> +static int __apply_alternatives(const struct alt_region *region,
> + paddr_t update_offset)
> {
> const struct alt_instr *alt;
> - const u32 *replptr;
> - u32 *origptr;
> + const u32 *replptr, *origptr;
> + u32 *updptr;
>
> printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
> region->begin, region->end);
> @@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region *region)
> BUG_ON(alt->alt_len != alt->orig_len);
>
> origptr = ALT_ORIG_PTR(alt);
> + updptr = (void *)origptr + update_offset;
> replptr = ALT_REPL_PTR(alt);
>
> nr_inst = alt->alt_len / sizeof(insn);
> @@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region *region)
> for ( i = 0; i < nr_inst; i++ )
> {
> insn = get_alt_insn(alt, origptr + i, replptr + i);
> - *(origptr + i) = cpu_to_le32(insn);
> + *(updptr + i) = cpu_to_le32(insn);
> }
>
> /* Ensure the new instructions reached the memory and nuke */
> @@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
> paddr_t xen_size = _end - _start;
> unsigned int xen_order = get_order_from_bytes(xen_size);
> void *xenmap;
> - struct virtual_region patch_region = {
> - .list = LIST_HEAD_INIT(patch_region.list),
> - };
>
> BUG_ON(patched);
>
> @@ -178,30 +180,19 @@ static int __apply_alternatives_multi_stop(void *unused)
> BUG_ON(!xenmap);
>
> /*
> - * If we generate a new branch instruction, the target will be
> - * calculated in this re-mapped Xen region. So we have to register
> - * this re-mapped Xen region as a virtual region temporarily.
> - */
> - patch_region.start = xenmap;
> - patch_region.end = xenmap + xen_size;
> - register_virtual_region(&patch_region);
> -
> - /*
> * Find the virtual address of the alternative region in the new
> * mapping.
> * alt_instr contains relative offset, so the function
> * __apply_alternatives will patch in the re-mapped version of
> * Xen.
> */
> - region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
> - region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
> + region.begin = __alt_instructions;
> + region.end = __alt_instructions_end;
>
> - ret = __apply_alternatives(®ion);
> + ret = __apply_alternatives(®ion, xenmap - (void *)_start);
> /* The patching is not expected to fail during boot. */
> BUG_ON(ret != 0);
>
> - unregister_virtual_region(&patch_region);
> -
> vunmap(xenmap);
>
> /* Barriers provided by the cache flushing */
> @@ -235,7 +226,7 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
> .end = end,
> };
>
> - return __apply_alternatives(®ion);
> + return __apply_alternatives(®ion, 0);
> }
>
> /*
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 07/13] xen/arm: Simplify alternative patching
2018-05-25 20:52 ` Stefano Stabellini
@ 2018-05-25 21:34 ` Julien Grall
2018-05-25 23:24 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-25 21:34 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: andre.przywara, Julien Grall, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 4770 bytes --]
On Fri, 25 May 2018, 22:54 Stefano Stabellini, <sstabellini@kernel.org>
wrote:
> You might want to CC Konrad next time on this patch
>
May I ask why? This code falls under Arm maintainership.
Cheers,
> On Tue, 22 May 2018, Julien Grall wrote:
> > This is part of XSA-263.
> >
> > Signed-off-by: Julien Grall <julien.grall@arm.com>
> >
> > ---
> > I am aware of the missing commit message here. I wanted to send the
> > series on the ML to get some feedback first.
> > ---
> > xen/arch/arm/alternative.c | 35 +++++++++++++----------------------
> > 1 file changed, 13 insertions(+), 22 deletions(-)
> >
> > diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> > index 9ffdc475d6..bd62183def 100644
> > --- a/xen/arch/arm/alternative.c
> > +++ b/xen/arch/arm/alternative.c
> > @@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
> > /*
> > * The region patched should be read-write to allow __apply_alternatives
> > * to replacing the instructions when necessary.
> > + *
> > + * @update_offset: Offset between the region patched and the writable
> > + * region for the update. 0 if the patched region is writable.
> > */
> > -static int __apply_alternatives(const struct alt_region *region)
> > +static int __apply_alternatives(const struct alt_region *region,
> > + paddr_t update_offset)
> > {
> > const struct alt_instr *alt;
> > - const u32 *replptr;
> > - u32 *origptr;
> > + const u32 *replptr, *origptr;
> > + u32 *updptr;
> >
> > printk(XENLOG_INFO "alternatives: Patching with alt table %p ->
> %p\n",
> > region->begin, region->end);
> > @@ -118,6 +122,7 @@ static int __apply_alternatives(const struct
> alt_region *region)
> > BUG_ON(alt->alt_len != alt->orig_len);
> >
> > origptr = ALT_ORIG_PTR(alt);
> > + updptr = (void *)origptr + update_offset;
> > replptr = ALT_REPL_PTR(alt);
> >
> > nr_inst = alt->alt_len / sizeof(insn);
> > @@ -125,7 +130,7 @@ static int __apply_alternatives(const struct
> alt_region *region)
> > for ( i = 0; i < nr_inst; i++ )
> > {
> > insn = get_alt_insn(alt, origptr + i, replptr + i);
> > - *(origptr + i) = cpu_to_le32(insn);
> > + *(updptr + i) = cpu_to_le32(insn);
> > }
> >
> > /* Ensure the new instructions reached the memory and nuke */
> > @@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void
> *unused)
> > paddr_t xen_size = _end - _start;
> > unsigned int xen_order = get_order_from_bytes(xen_size);
> > void *xenmap;
> > - struct virtual_region patch_region = {
> > - .list = LIST_HEAD_INIT(patch_region.list),
> > - };
> >
> > BUG_ON(patched);
> >
> > @@ -178,30 +180,19 @@ static int __apply_alternatives_multi_stop(void
> *unused)
> > BUG_ON(!xenmap);
> >
> > /*
> > - * If we generate a new branch instruction, the target will be
> > - * calculated in this re-mapped Xen region. So we have to
> register
> > - * this re-mapped Xen region as a virtual region temporarily.
> > - */
> > - patch_region.start = xenmap;
> > - patch_region.end = xenmap + xen_size;
> > - register_virtual_region(&patch_region);
> > -
> > - /*
> > * Find the virtual address of the alternative region in the new
> > * mapping.
> > * alt_instr contains relative offset, so the function
> > * __apply_alternatives will patch in the re-mapped version of
> > * Xen.
> > */
> > - region.begin = (void *)__alt_instructions - (void *)_start +
> xenmap;
> > - region.end = (void *)__alt_instructions_end - (void *)_start +
> xenmap;
> > + region.begin = __alt_instructions;
> > + region.end = __alt_instructions_end;
> >
> > - ret = __apply_alternatives(®ion);
> > + ret = __apply_alternatives(®ion, xenmap - (void *)_start);
> > /* The patching is not expected to fail during boot. */
> > BUG_ON(ret != 0);
> >
> > - unregister_virtual_region(&patch_region);
> > -
> > vunmap(xenmap);
> >
> > /* Barriers provided by the cache flushing */
> > @@ -235,7 +226,7 @@ int apply_alternatives(const struct alt_instr
> *start, const struct alt_instr *en
> > .end = end,
> > };
> >
> > - return __apply_alternatives(®ion);
> > + return __apply_alternatives(®ion, 0);
> > }
> >
> > /*
> > --
> > 2.11.0
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 6481 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 07/13] xen/arm: Simplify alternative patching
2018-05-25 21:34 ` Julien Grall
@ 2018-05-25 23:24 ` Stefano Stabellini
2018-05-29 11:34 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 23:24 UTC (permalink / raw)
To: Julien Grall; +Cc: andre.przywara, Julien Grall, Stefano Stabellini, xen-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5865 bytes --]
On Fri, 25 May 2018, Julien Grall wrote:
> On Fri, 25 May 2018, 22:54 Stefano Stabellini, <sstabellini@kernel.org> wrote:
> You might want to CC Konrad next time on this patch
>
>
> May I ask why? This code falls under Arm maintainership.
I know, but I appreciate his input if he has time for it
>
>
> On Tue, 22 May 2018, Julien Grall wrote:
> > This is part of XSA-263.
> >
> > Signed-off-by: Julien Grall <julien.grall@arm.com>
> >
> > ---
> > I am aware of the missing commit message here. I wanted to send the
> > series on the ML to get some feedback first.
> > ---
> > xen/arch/arm/alternative.c | 35 +++++++++++++----------------------
> > 1 file changed, 13 insertions(+), 22 deletions(-)
> >
> > diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> > index 9ffdc475d6..bd62183def 100644
> > --- a/xen/arch/arm/alternative.c
> > +++ b/xen/arch/arm/alternative.c
> > @@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
> > /*
> > * The region patched should be read-write to allow __apply_alternatives
> > * to replacing the instructions when necessary.
> > + *
> > + * @update_offset: Offset between the region patched and the writable
> > + * region for the update. 0 if the patched region is writable.
> > */
> > -static int __apply_alternatives(const struct alt_region *region)
> > +static int __apply_alternatives(const struct alt_region *region,
> > + paddr_t update_offset)
> > {
> > const struct alt_instr *alt;
> > - const u32 *replptr;
> > - u32 *origptr;
> > + const u32 *replptr, *origptr;
> > + u32 *updptr;
> >
> > printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
> > region->begin, region->end);
> > @@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region *region)
> > BUG_ON(alt->alt_len != alt->orig_len);
> >
> > origptr = ALT_ORIG_PTR(alt);
> > + updptr = (void *)origptr + update_offset;
> > replptr = ALT_REPL_PTR(alt);
> >
> > nr_inst = alt->alt_len / sizeof(insn);
> > @@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region *region)
> > for ( i = 0; i < nr_inst; i++ )
> > {
> > insn = get_alt_insn(alt, origptr + i, replptr + i);
> > - *(origptr + i) = cpu_to_le32(insn);
> > + *(updptr + i) = cpu_to_le32(insn);
> > }
> >
> > /* Ensure the new instructions reached the memory and nuke */
> > @@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
> > paddr_t xen_size = _end - _start;
> > unsigned int xen_order = get_order_from_bytes(xen_size);
> > void *xenmap;
> > - struct virtual_region patch_region = {
> > - .list = LIST_HEAD_INIT(patch_region.list),
> > - };
> >
> > BUG_ON(patched);
> >
> > @@ -178,30 +180,19 @@ static int __apply_alternatives_multi_stop(void *unused)
> > BUG_ON(!xenmap);
> >
> > /*
> > - * If we generate a new branch instruction, the target will be
> > - * calculated in this re-mapped Xen region. So we have to register
> > - * this re-mapped Xen region as a virtual region temporarily.
> > - */
> > - patch_region.start = xenmap;
> > - patch_region.end = xenmap + xen_size;
> > - register_virtual_region(&patch_region);
> > -
> > - /*
> > * Find the virtual address of the alternative region in the new
> > * mapping.
> > * alt_instr contains relative offset, so the function
> > * __apply_alternatives will patch in the re-mapped version of
> > * Xen.
> > */
> > - region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
> > - region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
> > + region.begin = __alt_instructions;
> > + region.end = __alt_instructions_end;
> >
> > - ret = __apply_alternatives(®ion);
> > + ret = __apply_alternatives(®ion, xenmap - (void *)_start);
> > /* The patching is not expected to fail during boot. */
> > BUG_ON(ret != 0);
> >
> > - unregister_virtual_region(&patch_region);
> > -
> > vunmap(xenmap);
> >
> > /* Barriers provided by the cache flushing */
> > @@ -235,7 +226,7 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
> > .end = end,
> > };
> >
> > - return __apply_alternatives(®ion);
> > + return __apply_alternatives(®ion, 0);
> > }
> >
> > /*
> > --
> > 2.11.0
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
>
>
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 07/13] xen/arm: Simplify alternative patching
2018-05-25 23:24 ` Stefano Stabellini
@ 2018-05-29 11:34 ` Julien Grall
0 siblings, 0 replies; 62+ messages in thread
From: Julien Grall @ 2018-05-29 11:34 UTC (permalink / raw)
To: Stefano Stabellini, Julien Grall; +Cc: andre.przywara, xen-devel
On 26/05/18 00:24, Stefano Stabellini wrote:
> On Fri, 25 May 2018, Julien Grall wrote:
>> On Fri, 25 May 2018, 22:54 Stefano Stabellini, <sstabellini@kernel.org> wrote:
>> You might want to CC Konrad next time on this patch
>>
>>
>> May I ask why? This code falls under Arm maintainership.
>
> I know, but I appreciate his input if he has time for it
I will, but you could also have CCed him from your first e-mail to give
him more time.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (6 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 07/13] xen/arm: Simplify alternative patching Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-25 20:52 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 09/13] xen/arm64: Add generic assembly macros Julien Grall
` (5 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
dynamic patching feature" written by Marc Zyngier:
We've so far relied on a patching infrastructure that only gave us
a single alternative, without any way to provide a range of potential
replacement instructions. For a single feature, this is an all or
nothing thing.
It would be interesting to have a more flexible grained way of patching the
kernel though, where we could dynamically tune the code that gets injected.
In order to achive this, let's introduce a new form of dynamic patching,
assiciating a callback to a patching site. This callback gets source and
target locations of the patching request, as well as the number of
instructions to be patched.
Dynamic patching is declared with the new ALTERNATIVE_CB and alternative_cb
directives:
asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
: "r" (v));
or
alternative_cb callback
mov x0, #0
alternative_cb_end
where callback is the C function computing the alternative.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
This is patch of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/alternative.c | 48 +++++++++++++++++++++++++++++----------
xen/include/asm-arm/alternative.h | 44 +++++++++++++++++++++++++++++++----
2 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index bd62183def..673150d1c0 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -30,6 +30,8 @@
#include <asm/byteorder.h>
#include <asm/cpufeature.h>
#include <asm/insn.h>
+/* XXX: Move ARCH_PATCH_INSN_SIZE out of livepatch.h */
+#include <asm/livepatch.h>
#include <asm/page.h>
/* Override macros from asm/page.h to make them work with mfn_t */
@@ -94,6 +96,23 @@ static u32 get_alt_insn(const struct alt_instr *alt,
return insn;
}
+static void patch_alternative(const struct alt_instr *alt,
+ const uint32_t *origptr,
+ uint32_t *updptr, int nr_inst)
+{
+ const uint32_t *replptr;
+ unsigned int i;
+
+ replptr = ALT_REPL_PTR(alt);
+ for ( i = 0; i < nr_inst; i++ )
+ {
+ uint32_t insn;
+
+ insn = get_alt_insn(alt, origptr + i, replptr + i);
+ updptr[i] = cpu_to_le32(insn);
+ }
+}
+
/*
* The region patched should be read-write to allow __apply_alternatives
* to replacing the instructions when necessary.
@@ -105,33 +124,38 @@ static int __apply_alternatives(const struct alt_region *region,
paddr_t update_offset)
{
const struct alt_instr *alt;
- const u32 *replptr, *origptr;
+ const u32 *origptr;
u32 *updptr;
+ alternative_cb_t alt_cb;
printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
for ( alt = region->begin; alt < region->end; alt++ )
{
- u32 insn;
- int i, nr_inst;
+ int nr_inst;
- if ( !cpus_have_cap(alt->cpufeature) )
+ /* Use ARM_CB_PATCH as an unconditional patch */
+ if ( alt->cpufeature < ARM_CB_PATCH &&
+ !cpus_have_cap(alt->cpufeature) )
continue;
- BUG_ON(alt->alt_len != alt->orig_len);
+ if ( alt->cpufeature == ARM_CB_PATCH )
+ BUG_ON(alt->alt_len != 0);
+ else
+ BUG_ON(alt->alt_len != alt->orig_len);
origptr = ALT_ORIG_PTR(alt);
updptr = (void *)origptr + update_offset;
- replptr = ALT_REPL_PTR(alt);
- nr_inst = alt->alt_len / sizeof(insn);
+ nr_inst = alt->orig_len / ARCH_PATCH_INSN_SIZE;
- for ( i = 0; i < nr_inst; i++ )
- {
- insn = get_alt_insn(alt, origptr + i, replptr + i);
- *(updptr + i) = cpu_to_le32(insn);
- }
+ if ( alt->cpufeature < ARM_CB_PATCH )
+ alt_cb = patch_alternative;
+ else
+ alt_cb = ALT_REPL_PTR(alt);
+
+ alt_cb(alt, origptr, updptr, nr_inst);
/* Ensure the new instructions reached the memory and nuke */
clean_and_invalidate_dcache_va_range(origptr,
diff --git a/xen/include/asm-arm/alternative.h b/xen/include/asm-arm/alternative.h
index 4e33d1cdf7..9b4b02811b 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -3,6 +3,8 @@
#include <asm/cpufeature.h>
+#define ARM_CB_PATCH ARM_NCAPS
+
#ifndef __ASSEMBLY__
#include <xen/init.h>
@@ -18,16 +20,24 @@ struct alt_instr {
};
/* Xen: helpers used by common code. */
-#define __ALT_PTR(a,f) ((u32 *)((void *)&(a)->f + (a)->f))
+#define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f)
#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
+typedef void (*alternative_cb_t)(const struct alt_instr *alt,
+ const uint32_t *origptr, uint32_t *updptr,
+ int nr_inst);
+
void __init apply_alternatives_all(void);
int apply_alternatives(const struct alt_instr *start, const struct alt_instr *end);
-#define ALTINSTR_ENTRY(feature) \
+#define ALTINSTR_ENTRY(feature, cb) \
" .word 661b - .\n" /* label */ \
+ " .if " __stringify(cb) " == 0\n" \
" .word 663f - .\n" /* new instruction */ \
+ " .else\n" \
+ " .word " __stringify(cb) "- .\n" /* callback */ \
+ " .endif\n" \
" .hword " __stringify(feature) "\n" /* feature bit */ \
" .byte 662b-661b\n" /* source len */ \
" .byte 664f-663f\n" /* replacement len */
@@ -45,15 +55,18 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
* but most assemblers die if insn1 or insn2 have a .inst. This should
* be fixed in a binutils release posterior to 2.25.51.0.2 (anything
* containing commit 4e4d08cf7399b606 or c1baaddf8861).
+ *
+ * Alternatives with callbacks do not generate replacement instructions.
*/
-#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg_enabled) \
+#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg_enabled, cb) \
".if "__stringify(cfg_enabled)" == 1\n" \
"661:\n\t" \
oldinstr "\n" \
"662:\n" \
".pushsection .altinstructions,\"a\"\n" \
- ALTINSTR_ENTRY(feature) \
+ ALTINSTR_ENTRY(feature,cb) \
".popsection\n" \
+ " .if " __stringify(cb) " == 0\n" \
".pushsection .altinstr_replacement, \"a\"\n" \
"663:\n\t" \
newinstr "\n" \
@@ -61,11 +74,17 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
".popsection\n\t" \
".org . - (664b-663b) + (662b-661b)\n\t" \
".org . - (662b-661b) + (664b-663b)\n" \
+ ".else\n\t" \
+ "663:\n\t" \
+ "664:\n\t" \
+ ".endif\n" \
".endif\n"
#define _ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg, ...) \
- __ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg))
+ __ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg), 0)
+#define ALTERNATIVE_CB(oldinstr, cb) \
+ __ALTERNATIVE_CFG(oldinstr, "NOT_AN_INSTRUCTION", ARM_CB_PATCH, 1, cb)
#else
#include <asm/asm_defns.h>
@@ -126,6 +145,14 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
663:
.endm
+.macro alternative_cb cb
+ .set .Lasm_alt_mode, 0
+ .pushsection .altinstructions, "a"
+ altinstruction_entry 661f, \cb, ARM_CB_PATCH, 662f-661f, 0
+ .popsection
+661:
+.endm
+
/*
* Complete an alternative code sequence.
*/
@@ -135,6 +162,13 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
.org . - (662b-661b) + (664b-663b)
.endm
+/*
+ * Callback-based alternative epilogue
+ */
+.macro alternative_cb_end
+662:
+.endm
+
#define _ALTERNATIVE_CFG(insn1, insn2, cap, cfg, ...) \
alternative_insn insn1, insn2, cap, IS_ENABLED(cfg)
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature
2018-05-22 17:42 ` [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature Julien Grall
@ 2018-05-25 20:52 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 20:52 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
> dynamic patching feature" written by Marc Zyngier:
>
> We've so far relied on a patching infrastructure that only gave us
> a single alternative, without any way to provide a range of potential
> replacement instructions. For a single feature, this is an all or
> nothing thing.
>
> It would be interesting to have a more flexible grained way of patching the
> kernel though, where we could dynamically tune the code that gets injected.
>
> In order to achive this, let's introduce a new form of dynamic patching,
> assiciating a callback to a patching site. This callback gets source and
> target locations of the patching request, as well as the number of
> instructions to be patched.
>
> Dynamic patching is declared with the new ALTERNATIVE_CB and alternative_cb
> directives:
> asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
> : "r" (v));
> or
>
> alternative_cb callback
> mov x0, #0
> alternative_cb_end
>
> where callback is the C function computing the alternative.
>
> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> This is patch of XSA-263.
This patch is part of XSA-263.
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/arch/arm/alternative.c | 48 +++++++++++++++++++++++++++++----------
> xen/include/asm-arm/alternative.h | 44 +++++++++++++++++++++++++++++++----
> 2 files changed, 75 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> index bd62183def..673150d1c0 100644
> --- a/xen/arch/arm/alternative.c
> +++ b/xen/arch/arm/alternative.c
> @@ -30,6 +30,8 @@
> #include <asm/byteorder.h>
> #include <asm/cpufeature.h>
> #include <asm/insn.h>
> +/* XXX: Move ARCH_PATCH_INSN_SIZE out of livepatch.h */
> +#include <asm/livepatch.h>
> #include <asm/page.h>
>
> /* Override macros from asm/page.h to make them work with mfn_t */
> @@ -94,6 +96,23 @@ static u32 get_alt_insn(const struct alt_instr *alt,
> return insn;
> }
>
> +static void patch_alternative(const struct alt_instr *alt,
> + const uint32_t *origptr,
> + uint32_t *updptr, int nr_inst)
> +{
> + const uint32_t *replptr;
> + unsigned int i;
> +
> + replptr = ALT_REPL_PTR(alt);
> + for ( i = 0; i < nr_inst; i++ )
> + {
> + uint32_t insn;
> +
> + insn = get_alt_insn(alt, origptr + i, replptr + i);
> + updptr[i] = cpu_to_le32(insn);
> + }
> +}
> +
> /*
> * The region patched should be read-write to allow __apply_alternatives
> * to replacing the instructions when necessary.
> @@ -105,33 +124,38 @@ static int __apply_alternatives(const struct alt_region *region,
> paddr_t update_offset)
> {
> const struct alt_instr *alt;
> - const u32 *replptr, *origptr;
> + const u32 *origptr;
> u32 *updptr;
> + alternative_cb_t alt_cb;
>
> printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
> region->begin, region->end);
>
> for ( alt = region->begin; alt < region->end; alt++ )
> {
> - u32 insn;
> - int i, nr_inst;
> + int nr_inst;
>
> - if ( !cpus_have_cap(alt->cpufeature) )
> + /* Use ARM_CB_PATCH as an unconditional patch */
> + if ( alt->cpufeature < ARM_CB_PATCH &&
> + !cpus_have_cap(alt->cpufeature) )
> continue;
>
> - BUG_ON(alt->alt_len != alt->orig_len);
> + if ( alt->cpufeature == ARM_CB_PATCH )
> + BUG_ON(alt->alt_len != 0);
> + else
> + BUG_ON(alt->alt_len != alt->orig_len);
>
> origptr = ALT_ORIG_PTR(alt);
> updptr = (void *)origptr + update_offset;
> - replptr = ALT_REPL_PTR(alt);
>
> - nr_inst = alt->alt_len / sizeof(insn);
> + nr_inst = alt->orig_len / ARCH_PATCH_INSN_SIZE;
>
> - for ( i = 0; i < nr_inst; i++ )
> - {
> - insn = get_alt_insn(alt, origptr + i, replptr + i);
> - *(updptr + i) = cpu_to_le32(insn);
> - }
> + if ( alt->cpufeature < ARM_CB_PATCH )
> + alt_cb = patch_alternative;
> + else
> + alt_cb = ALT_REPL_PTR(alt);
> +
> + alt_cb(alt, origptr, updptr, nr_inst);
>
> /* Ensure the new instructions reached the memory and nuke */
> clean_and_invalidate_dcache_va_range(origptr,
> diff --git a/xen/include/asm-arm/alternative.h b/xen/include/asm-arm/alternative.h
> index 4e33d1cdf7..9b4b02811b 100644
> --- a/xen/include/asm-arm/alternative.h
> +++ b/xen/include/asm-arm/alternative.h
> @@ -3,6 +3,8 @@
>
> #include <asm/cpufeature.h>
>
> +#define ARM_CB_PATCH ARM_NCAPS
> +
> #ifndef __ASSEMBLY__
>
> #include <xen/init.h>
> @@ -18,16 +20,24 @@ struct alt_instr {
> };
>
> /* Xen: helpers used by common code. */
> -#define __ALT_PTR(a,f) ((u32 *)((void *)&(a)->f + (a)->f))
> +#define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f)
> #define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
> #define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
>
> +typedef void (*alternative_cb_t)(const struct alt_instr *alt,
> + const uint32_t *origptr, uint32_t *updptr,
> + int nr_inst);
> +
> void __init apply_alternatives_all(void);
> int apply_alternatives(const struct alt_instr *start, const struct alt_instr *end);
>
> -#define ALTINSTR_ENTRY(feature) \
> +#define ALTINSTR_ENTRY(feature, cb) \
> " .word 661b - .\n" /* label */ \
> + " .if " __stringify(cb) " == 0\n" \
> " .word 663f - .\n" /* new instruction */ \
> + " .else\n" \
> + " .word " __stringify(cb) "- .\n" /* callback */ \
> + " .endif\n" \
> " .hword " __stringify(feature) "\n" /* feature bit */ \
> " .byte 662b-661b\n" /* source len */ \
> " .byte 664f-663f\n" /* replacement len */
> @@ -45,15 +55,18 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
> * but most assemblers die if insn1 or insn2 have a .inst. This should
> * be fixed in a binutils release posterior to 2.25.51.0.2 (anything
> * containing commit 4e4d08cf7399b606 or c1baaddf8861).
> + *
> + * Alternatives with callbacks do not generate replacement instructions.
> */
> -#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg_enabled) \
> +#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg_enabled, cb) \
> ".if "__stringify(cfg_enabled)" == 1\n" \
> "661:\n\t" \
> oldinstr "\n" \
> "662:\n" \
> ".pushsection .altinstructions,\"a\"\n" \
> - ALTINSTR_ENTRY(feature) \
> + ALTINSTR_ENTRY(feature,cb) \
> ".popsection\n" \
> + " .if " __stringify(cb) " == 0\n" \
> ".pushsection .altinstr_replacement, \"a\"\n" \
> "663:\n\t" \
> newinstr "\n" \
> @@ -61,11 +74,17 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
> ".popsection\n\t" \
> ".org . - (664b-663b) + (662b-661b)\n\t" \
> ".org . - (662b-661b) + (664b-663b)\n" \
> + ".else\n\t" \
> + "663:\n\t" \
> + "664:\n\t" \
> + ".endif\n" \
> ".endif\n"
>
> #define _ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg, ...) \
> - __ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg))
> + __ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg), 0)
>
> +#define ALTERNATIVE_CB(oldinstr, cb) \
> + __ALTERNATIVE_CFG(oldinstr, "NOT_AN_INSTRUCTION", ARM_CB_PATCH, 1, cb)
> #else
>
> #include <asm/asm_defns.h>
> @@ -126,6 +145,14 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
> 663:
> .endm
>
> +.macro alternative_cb cb
> + .set .Lasm_alt_mode, 0
> + .pushsection .altinstructions, "a"
> + altinstruction_entry 661f, \cb, ARM_CB_PATCH, 662f-661f, 0
> + .popsection
> +661:
> +.endm
> +
> /*
> * Complete an alternative code sequence.
> */
> @@ -135,6 +162,13 @@ int apply_alternatives(const struct alt_instr *start, const struct alt_instr *en
> .org . - (662b-661b) + (664b-663b)
> .endm
>
> +/*
> + * Callback-based alternative epilogue
> + */
> +.macro alternative_cb_end
> +662:
> +.endm
> +
> #define _ALTERNATIVE_CFG(insn1, insn2, cap, cfg, ...) \
> alternative_insn insn1, insn2, cap, IS_ENABLED(cfg)
>
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 09/13] xen/arm64: Add generic assembly macros
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (7 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 23:37 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2 Julien Grall
` (4 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
Add assembly macros to simplify assembly code:
- adr_cpu_info: Get the address to the current cpu_info structure
- ldr_this_cpu: Load a per-cpu value
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/include/asm-arm/arm64/macros.h | 25 +++++++++++++++++++++++++
xen/include/asm-arm/macros.h | 2 +-
2 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 xen/include/asm-arm/arm64/macros.h
diff --git a/xen/include/asm-arm/arm64/macros.h b/xen/include/asm-arm/arm64/macros.h
new file mode 100644
index 0000000000..9c5e676b37
--- /dev/null
+++ b/xen/include/asm-arm/arm64/macros.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_ARM_ARM64_MACROS_H
+#define __ASM_ARM_ARM64_MACROS_H
+
+ /*
+ * @dst: Result of get_cpu_info()
+ */
+ .macro adr_cpu_info, dst
+ add \dst, sp, #STACK_SIZE
+ and \dst, \dst, #~(STACK_SIZE - 1)
+ sub \dst, \dst, #CPUINFO_sizeof
+ .endm
+
+ /*
+ * @dst: Result of READ_ONCE(per_cpu(sym, smp_processor_id()))
+ * @sym: The name of the per-cpu variable
+ * @tmp: scratch register
+ */
+ .macro ldr_this_cpu, dst, sym, tmp
+ ldr \dst, =per_cpu__\sym
+ mrs \tmp, tpidr_el2
+ ldr \dst, [\dst, \tmp]
+ .endm
+
+#endif /* __ASM_ARM_ARM64_MACROS_H */
+
diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h
index 5d837cb38b..1d4bb41d15 100644
--- a/xen/include/asm-arm/macros.h
+++ b/xen/include/asm-arm/macros.h
@@ -8,7 +8,7 @@
#if defined (CONFIG_ARM_32)
# include <asm/arm32/macros.h>
#elif defined(CONFIG_ARM_64)
-/* No specific ARM64 macros for now */
+# include <asm/arm64/macros.h>
#else
# error "unknown ARM variant"
#endif
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 09/13] xen/arm64: Add generic assembly macros
2018-05-22 17:42 ` [PATCH 09/13] xen/arm64: Add generic assembly macros Julien Grall
@ 2018-05-23 23:37 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 23:37 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> Add assembly macros to simplify assembly code:
> - adr_cpu_info: Get the address to the current cpu_info structure
> - ldr_this_cpu: Load a per-cpu value
>
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/include/asm-arm/arm64/macros.h | 25 +++++++++++++++++++++++++
> xen/include/asm-arm/macros.h | 2 +-
> 2 files changed, 26 insertions(+), 1 deletion(-)
> create mode 100644 xen/include/asm-arm/arm64/macros.h
>
> diff --git a/xen/include/asm-arm/arm64/macros.h b/xen/include/asm-arm/arm64/macros.h
> new file mode 100644
> index 0000000000..9c5e676b37
> --- /dev/null
> +++ b/xen/include/asm-arm/arm64/macros.h
> @@ -0,0 +1,25 @@
> +#ifndef __ASM_ARM_ARM64_MACROS_H
> +#define __ASM_ARM_ARM64_MACROS_H
> +
> + /*
> + * @dst: Result of get_cpu_info()
> + */
> + .macro adr_cpu_info, dst
> + add \dst, sp, #STACK_SIZE
> + and \dst, \dst, #~(STACK_SIZE - 1)
> + sub \dst, \dst, #CPUINFO_sizeof
> + .endm
> +
> + /*
> + * @dst: Result of READ_ONCE(per_cpu(sym, smp_processor_id()))
> + * @sym: The name of the per-cpu variable
> + * @tmp: scratch register
> + */
> + .macro ldr_this_cpu, dst, sym, tmp
> + ldr \dst, =per_cpu__\sym
> + mrs \tmp, tpidr_el2
> + ldr \dst, [\dst, \tmp]
> + .endm
> +
> +#endif /* __ASM_ARM_ARM64_MACROS_H */
> +
> diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h
> index 5d837cb38b..1d4bb41d15 100644
> --- a/xen/include/asm-arm/macros.h
> +++ b/xen/include/asm-arm/macros.h
> @@ -8,7 +8,7 @@
> #if defined (CONFIG_ARM_32)
> # include <asm/arm32/macros.h>
> #elif defined(CONFIG_ARM_64)
> -/* No specific ARM64 macros for now */
> +# include <asm/arm64/macros.h>
> #else
> # error "unknown ARM variant"
> #endif
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (8 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 09/13] xen/arm64: Add generic assembly macros Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-25 19:18 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features" Julien Grall
` (3 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
enabling/disabling the ssbd mitigation. So we want the handling to
be as fast as possible.
The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
also track the state of the workaround per-vCPU.
Note that since we need to execute branches, this always executes after
the spectre-v2 mitigation.
This code is based on KVM counterpart "arm64: KVM: Handle guest's
ARCH_WORKAROUND_2 requests" written by Marc Zyngier.
This is part of XSA-263.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/arm64/asm-offsets.c | 2 ++
xen/arch/arm/arm64/entry.S | 43 +++++++++++++++++++++++++++++++++++++++-
xen/arch/arm/cpuerrata.c | 18 +++++++++++++++++
3 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index ce24e44473..f5c696d092 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -22,6 +22,7 @@
void __dummy__(void)
{
OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+ OFFSET(UREGS_X1, struct cpu_user_regs, x1);
OFFSET(UREGS_LR, struct cpu_user_regs, lr);
OFFSET(UREGS_SP, struct cpu_user_regs, sp);
@@ -45,6 +46,7 @@ void __dummy__(void)
BLANK();
DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+ OFFSET(CPUINFO_flags, struct cpu_info, flags);
OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index e2344e565f..8e25ff3997 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,4 +1,6 @@
#include <asm/asm_defns.h>
+#include <asm/current.h>
+#include <asm/macros.h>
#include <asm/regs.h>
#include <asm/alternative.h>
#include <asm/smccc.h>
@@ -241,7 +243,7 @@ guest_sync:
* be encoded as an immediate for cmp.
*/
eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
- cbnz w0, guest_sync_slowpath
+ cbnz w0, check_wa2
/*
* Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,6 +252,45 @@ guest_sync:
mov x1, xzr
eret
+check_wa2:
+ /* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
+ eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+ eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
+ cbnz w0, guest_sync_slowpath
+#ifdef CONFIG_ARM_SSBD
+alternative_cb arm_enable_wa2_handling
+ b wa2_end
+alternative_cb_end
+ /* Sanitize the argument */
+ mov x0, #-(UREGS_kernel_sizeof - UREGS_X1) /* x0 := offset of guest's x1 on the stack */
+ ldr x1, [sp, x0] /* Load guest's x1 */
+ cmp w1, wzr
+ cset x1, ne
+
+ /*
+ * Update the guest flag. At this stage sp point after the field
+ * guest_cpu_user_regs in cpu_info.
+ */
+ adr_cpu_info x2
+ ldr x0, [x2, #CPUINFO_flags]
+ bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
+ str x0, [x2, #CPUINFO_flags]
+
+ /* Check that we actually need to perform the call */
+ ldr_this_cpu x0, ssbd_callback_required, x2
+ cbz x0, wa2_end
+
+ mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
+ smc #0
+
+wa2_end:
+ /* Don't leak data from the SMC call */
+ mov x1, xzr
+ mov x2, xzr
+ mov x3, xzr
+#endif /* !CONFIG_ARM_SSBD */
+ mov x0, xzr
+ eret
guest_sync_slowpath:
/*
* x0/x1 may have been scratch by the fast path above, so avoid
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index f921721a66..54df4ff445 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -7,6 +7,7 @@
#include <xen/warning.h>
#include <asm/cpufeature.h>
#include <asm/cpuerrata.h>
+#include <asm/insn.h>
#include <asm/psci.h>
/* Override macros from asm/page.h to make them work with mfn_t */
@@ -272,6 +273,23 @@ static int __init parse_spec_ctrl(const char *s)
}
custom_param("spec-ctrl", parse_spec_ctrl);
+/* Arm64 only for now as for Arm32 the workaround is currently handled in C. */
+#ifdef CONFIG_ARM_64
+void __init arm_enable_wa2_handling(const struct alt_instr *alt,
+ const uint32_t *origptr,
+ uint32_t *updptr, int nr_inst)
+{
+ BUG_ON(nr_inst != 1);
+
+ /*
+ * Only allow mitigation on guest ARCH_WORKAROUND_2 if the SSBD
+ * state allow it to be flipped.
+ */
+ if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+ *updptr = aarch64_insn_gen_nop();
+}
+#endif
+
/*
* Assembly code may use the variable directly, so we need to make sure
* it fits in a register.
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
2018-05-22 17:42 ` [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2 Julien Grall
@ 2018-05-25 19:18 ` Stefano Stabellini
2018-05-29 12:16 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-25 19:18 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
> enabling/disabling the ssbd mitigation. So we want the handling to
> be as fast as possible.
>
> The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
> also track the state of the workaround per-vCPU.
>
> Note that since we need to execute branches, this always executes after
> the spectre-v2 mitigation.
>
> This code is based on KVM counterpart "arm64: KVM: Handle guest's
> ARCH_WORKAROUND_2 requests" written by Marc Zyngier.
>
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
I think the patch works as intended.
> ---
> xen/arch/arm/arm64/asm-offsets.c | 2 ++
> xen/arch/arm/arm64/entry.S | 43 +++++++++++++++++++++++++++++++++++++++-
> xen/arch/arm/cpuerrata.c | 18 +++++++++++++++++
> 3 files changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
> index ce24e44473..f5c696d092 100644
> --- a/xen/arch/arm/arm64/asm-offsets.c
> +++ b/xen/arch/arm/arm64/asm-offsets.c
> @@ -22,6 +22,7 @@
> void __dummy__(void)
> {
> OFFSET(UREGS_X0, struct cpu_user_regs, x0);
> + OFFSET(UREGS_X1, struct cpu_user_regs, x1);
> OFFSET(UREGS_LR, struct cpu_user_regs, lr);
>
> OFFSET(UREGS_SP, struct cpu_user_regs, sp);
> @@ -45,6 +46,7 @@ void __dummy__(void)
> BLANK();
>
> DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
> + OFFSET(CPUINFO_flags, struct cpu_info, flags);
>
> OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
>
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index e2344e565f..8e25ff3997 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -1,4 +1,6 @@
> #include <asm/asm_defns.h>
> +#include <asm/current.h>
> +#include <asm/macros.h>
> #include <asm/regs.h>
> #include <asm/alternative.h>
> #include <asm/smccc.h>
> @@ -241,7 +243,7 @@ guest_sync:
> * be encoded as an immediate for cmp.
> */
> eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> - cbnz w0, guest_sync_slowpath
> + cbnz w0, check_wa2
>
> /*
> * Clobber both x0 and x1 to prevent leakage. Note that thanks
> @@ -250,6 +252,45 @@ guest_sync:
> mov x1, xzr
> eret
>
> +check_wa2:
> + /* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
> + eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
We come to check_wa2 after checking on #ARM_SMCCC_ARCH_WORKAROUND_1_FID,
so maybe we can skip this?
> + eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
> + cbnz w0, guest_sync_slowpath
> +#ifdef CONFIG_ARM_SSBD
> +alternative_cb arm_enable_wa2_handling
> + b wa2_end
> +alternative_cb_end
> + /* Sanitize the argument */
> + mov x0, #-(UREGS_kernel_sizeof - UREGS_X1) /* x0 := offset of guest's x1 on the stack */
> + ldr x1, [sp, x0] /* Load guest's x1 */
> + cmp w1, wzr
> + cset x1, ne
> +
> + /*
> + * Update the guest flag. At this stage sp point after the field
> + * guest_cpu_user_regs in cpu_info.
> + */
> + adr_cpu_info x2
> + ldr x0, [x2, #CPUINFO_flags]
> + bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
> + str x0, [x2, #CPUINFO_flags]
> +
> + /* Check that we actually need to perform the call */
> + ldr_this_cpu x0, ssbd_callback_required, x2
> + cbz x0, wa2_end
> + mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
> + smc #0
Shouldn't we make the call only if get_cpu_info()->flags changed?
> +wa2_end:
> + /* Don't leak data from the SMC call */
> + mov x1, xzr
> + mov x2, xzr
> + mov x3, xzr
> +#endif /* !CONFIG_ARM_SSBD */
> + mov x0, xzr
> + eret
> guest_sync_slowpath:
> /*
> * x0/x1 may have been scratch by the fast path above, so avoid
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index f921721a66..54df4ff445 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -7,6 +7,7 @@
> #include <xen/warning.h>
> #include <asm/cpufeature.h>
> #include <asm/cpuerrata.h>
> +#include <asm/insn.h>
> #include <asm/psci.h>
>
> /* Override macros from asm/page.h to make them work with mfn_t */
> @@ -272,6 +273,23 @@ static int __init parse_spec_ctrl(const char *s)
> }
> custom_param("spec-ctrl", parse_spec_ctrl);
>
> +/* Arm64 only for now as for Arm32 the workaround is currently handled in C. */
> +#ifdef CONFIG_ARM_64
> +void __init arm_enable_wa2_handling(const struct alt_instr *alt,
> + const uint32_t *origptr,
> + uint32_t *updptr, int nr_inst)
> +{
> + BUG_ON(nr_inst != 1);
> +
> + /*
> + * Only allow mitigation on guest ARCH_WORKAROUND_2 if the SSBD
> + * state allow it to be flipped.
> + */
> + if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
> + *updptr = aarch64_insn_gen_nop();
> +}
> +#endif
> +
> /*
> * Assembly code may use the variable directly, so we need to make sure
> * it fits in a register.
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
2018-05-25 19:18 ` Stefano Stabellini
@ 2018-05-29 12:16 ` Julien Grall
2018-05-29 21:39 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-29 12:16 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 25/05/18 20:18, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
>> enabling/disabling the ssbd mitigation. So we want the handling to
>> be as fast as possible.
>>
>> The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
>> also track the state of the workaround per-vCPU.
>>
>> Note that since we need to execute branches, this always executes after
>> the spectre-v2 mitigation.
>>
>> This code is based on KVM counterpart "arm64: KVM: Handle guest's
>> ARCH_WORKAROUND_2 requests" written by Marc Zyngier.
>>
>> This is part of XSA-263.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> I think the patch works as intended.
>
>
>> ---
>> xen/arch/arm/arm64/asm-offsets.c | 2 ++
>> xen/arch/arm/arm64/entry.S | 43 +++++++++++++++++++++++++++++++++++++++-
>> xen/arch/arm/cpuerrata.c | 18 +++++++++++++++++
>> 3 files changed, 62 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
>> index ce24e44473..f5c696d092 100644
>> --- a/xen/arch/arm/arm64/asm-offsets.c
>> +++ b/xen/arch/arm/arm64/asm-offsets.c
>> @@ -22,6 +22,7 @@
>> void __dummy__(void)
>> {
>> OFFSET(UREGS_X0, struct cpu_user_regs, x0);
>> + OFFSET(UREGS_X1, struct cpu_user_regs, x1);
>> OFFSET(UREGS_LR, struct cpu_user_regs, lr);
>>
>> OFFSET(UREGS_SP, struct cpu_user_regs, sp);
>> @@ -45,6 +46,7 @@ void __dummy__(void)
>> BLANK();
>>
>> DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
>> + OFFSET(CPUINFO_flags, struct cpu_info, flags);
>>
>> OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
>>
>> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
>> index e2344e565f..8e25ff3997 100644
>> --- a/xen/arch/arm/arm64/entry.S
>> +++ b/xen/arch/arm/arm64/entry.S
>> @@ -1,4 +1,6 @@
>> #include <asm/asm_defns.h>
>> +#include <asm/current.h>
>> +#include <asm/macros.h>
>> #include <asm/regs.h>
>> #include <asm/alternative.h>
>> #include <asm/smccc.h>
>> @@ -241,7 +243,7 @@ guest_sync:
>> * be encoded as an immediate for cmp.
>> */
>> eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
>> - cbnz w0, guest_sync_slowpath
>> + cbnz w0, check_wa2
>>
>> /*
>> * Clobber both x0 and x1 to prevent leakage. Note that thanks
>> @@ -250,6 +252,45 @@ guest_sync:
>> mov x1, xzr
>> eret
>>
>> +check_wa2:
>> + /* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
>> + eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
>
> We come to check_wa2 after checking on #ARM_SMCCC_ARCH_WORKAROUND_1_FID,
> so maybe we can skip this?
This is necessary. w0 contains "guest x0" xor
"ARM_SMCCC_ARCH_WORKAROUND_1_FID". So we first need to revert back the
xor to get "guest x0".
Note, it would be possible to combine the 2 xor. Something like:
eor w0, w0, #(ARM_SMCCC_ARCH_WORKAROUND_1_FID ^
ARM_SMCCC_ARCH_WORKAROUND_2_FID).
Which version do you prefer?
>
>
>> + eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
>> + cbnz w0, guest_sync_slowpath
>> +#ifdef CONFIG_ARM_SSBD
>> +alternative_cb arm_enable_wa2_handling
>> + b wa2_end
>> +alternative_cb_end
>> + /* Sanitize the argument */
>> + mov x0, #-(UREGS_kernel_sizeof - UREGS_X1) /* x0 := offset of guest's x1 on the stack */
>> + ldr x1, [sp, x0] /* Load guest's x1 */
>> + cmp w1, wzr
>> + cset x1, ne
>> +
>> + /*
>> + * Update the guest flag. At this stage sp point after the field
>> + * guest_cpu_user_regs in cpu_info.
>> + */
>> + adr_cpu_info x2
>> + ldr x0, [x2, #CPUINFO_flags]
>> + bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
>> + str x0, [x2, #CPUINFO_flags]
>> +
>> + /* Check that we actually need to perform the call */
>> + ldr_this_cpu x0, ssbd_callback_required, x2
>> + cbz x0, wa2_end
>> + mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
>> + smc #0
>
> Shouldn't we make the call only if get_cpu_info()->flags changed?
There are no harm to call ARCH_WORKAROUND_2 if the flag didn't changed.
However the guest should already avoid to do the call when it is not
necessary. So that's not a common case that we should care.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
2018-05-29 12:16 ` Julien Grall
@ 2018-05-29 21:39 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-29 21:39 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Tue, 29 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 25/05/18 20:18, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
> > > enabling/disabling the ssbd mitigation. So we want the handling to
> > > be as fast as possible.
> > >
> > > The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
> > > also track the state of the workaround per-vCPU.
> > >
> > > Note that since we need to execute branches, this always executes after
> > > the spectre-v2 mitigation.
> > >
> > > This code is based on KVM counterpart "arm64: KVM: Handle guest's
> > > ARCH_WORKAROUND_2 requests" written by Marc Zyngier.
> > >
> > > This is part of XSA-263.
> > >
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> >
> > I think the patch works as intended.
> >
> >
> > > ---
> > > xen/arch/arm/arm64/asm-offsets.c | 2 ++
> > > xen/arch/arm/arm64/entry.S | 43
> > > +++++++++++++++++++++++++++++++++++++++-
> > > xen/arch/arm/cpuerrata.c | 18 +++++++++++++++++
> > > 3 files changed, 62 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/xen/arch/arm/arm64/asm-offsets.c
> > > b/xen/arch/arm/arm64/asm-offsets.c
> > > index ce24e44473..f5c696d092 100644
> > > --- a/xen/arch/arm/arm64/asm-offsets.c
> > > +++ b/xen/arch/arm/arm64/asm-offsets.c
> > > @@ -22,6 +22,7 @@
> > > void __dummy__(void)
> > > {
> > > OFFSET(UREGS_X0, struct cpu_user_regs, x0);
> > > + OFFSET(UREGS_X1, struct cpu_user_regs, x1);
> > > OFFSET(UREGS_LR, struct cpu_user_regs, lr);
> > > OFFSET(UREGS_SP, struct cpu_user_regs, sp);
> > > @@ -45,6 +46,7 @@ void __dummy__(void)
> > > BLANK();
> > > DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
> > > + OFFSET(CPUINFO_flags, struct cpu_info, flags);
> > > OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
> > > diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> > > index e2344e565f..8e25ff3997 100644
> > > --- a/xen/arch/arm/arm64/entry.S
> > > +++ b/xen/arch/arm/arm64/entry.S
> > > @@ -1,4 +1,6 @@
> > > #include <asm/asm_defns.h>
> > > +#include <asm/current.h>
> > > +#include <asm/macros.h>
> > > #include <asm/regs.h>
> > > #include <asm/alternative.h>
> > > #include <asm/smccc.h>
> > > @@ -241,7 +243,7 @@ guest_sync:
> > > * be encoded as an immediate for cmp.
> > > */
> > > eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> > > - cbnz w0, guest_sync_slowpath
> > > + cbnz w0, check_wa2
> > > /*
> > > * Clobber both x0 and x1 to prevent leakage. Note that thanks
> > > @@ -250,6 +252,45 @@ guest_sync:
> > > mov x1, xzr
> > > eret
> > > +check_wa2:
> > > + /* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
> > > + eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> >
> > We come to check_wa2 after checking on #ARM_SMCCC_ARCH_WORKAROUND_1_FID,
> > so maybe we can skip this?
>
> This is necessary. w0 contains "guest x0" xor
> "ARM_SMCCC_ARCH_WORKAROUND_1_FID". So we first need to revert back the xor to
> get "guest x0".
>
> Note, it would be possible to combine the 2 xor. Something like:
>
> eor w0, w0, #(ARM_SMCCC_ARCH_WORKAROUND_1_FID ^
> ARM_SMCCC_ARCH_WORKAROUND_2_FID).
>
> Which version do you prefer?
I understand now. Let's combine the two xor.
> > > + eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
> > > + cbnz w0, guest_sync_slowpath
> > > +#ifdef CONFIG_ARM_SSBD
> > > +alternative_cb arm_enable_wa2_handling
> > > + b wa2_end
> > > +alternative_cb_end
> > > + /* Sanitize the argument */
> > > + mov x0, #-(UREGS_kernel_sizeof - UREGS_X1) /* x0 := offset
> > > of guest's x1 on the stack */
> > > + ldr x1, [sp, x0] /* Load guest's
> > > x1 */
> > > + cmp w1, wzr
> > > + cset x1, ne
> > > +
> > > + /*
> > > + * Update the guest flag. At this stage sp point after the field
> > > + * guest_cpu_user_regs in cpu_info.
> > > + */
> > > + adr_cpu_info x2
> > > + ldr x0, [x2, #CPUINFO_flags]
> > > + bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
> > > + str x0, [x2, #CPUINFO_flags]
> > > +
> > > + /* Check that we actually need to perform the call */
> > > + ldr_this_cpu x0, ssbd_callback_required, x2
> > > + cbz x0, wa2_end
> > > + mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
> > > + smc #0
> >
> > Shouldn't we make the call only if get_cpu_info()->flags changed?
>
> There are no harm to call ARCH_WORKAROUND_2 if the flag didn't changed.
> However the guest should already avoid to do the call when it is not
> necessary. So that's not a common case that we should care.
All right
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features"
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (9 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2 Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 23:45 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID Julien Grall
` (2 subsequent siblings)
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making
impossible for the user to unselect it.
Also, it looks like we require to use 'expert = "y"' for showing the
option in expert mode.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/Kconfig | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 0e2d027060..4212c58171 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -83,6 +83,23 @@ config ARM_SSBD
If unsure, say Y.
+config HARDEN_BRANCH_PREDICTOR
+ bool "Harden the branch predictor against aliasing attacks" if EXPERT = "y"
+ default y
+ help
+ Speculation attacks against some high-performance processors rely on
+ being able to manipulate the branch predictor for a victim context by
+ executing aliasing branches in the attacker context. Such attacks
+ can be partially mitigated against by clearing internal branch
+ predictor state and limiting the prediction logic in some situations.
+
+ This config option will take CPU-specific actions to harden the
+ branch predictor against aliasing attacks and may rely on specific
+ instruction sequences or control bits being set by the system
+ firmware.
+
+ If unsure, say Y.
+
endmenu
menu "ARM errata workaround via the alternative framework"
@@ -197,23 +214,6 @@ config ARM64_ERRATUM_834220
endmenu
-config HARDEN_BRANCH_PREDICTOR
- bool "Harden the branch predictor against aliasing attacks" if EXPERT
- default y
- help
- Speculation attacks against some high-performance processors rely on
- being able to manipulate the branch predictor for a victim context by
- executing aliasing branches in the attacker context. Such attacks
- can be partially mitigated against by clearing internal branch
- predictor state and limiting the prediction logic in some situations.
-
- This config option will take CPU-specific actions to harden the
- branch predictor against aliasing attacks and may rely on specific
- instruction sequences or control bits being set by the system
- firmware.
-
- If unsure, say Y.
-
config ARM64_HARDEN_BRANCH_PREDICTOR
def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features"
2018-05-22 17:42 ` [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features" Julien Grall
@ 2018-05-23 23:45 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 23:45 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making
> impossible for the user to unselect it.
>
> Also, it looks like we require to use 'expert = "y"' for showing the
> option in expert mode.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Very useful, thank you!
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/arch/arm/Kconfig | 34 +++++++++++++++++-----------------
> 1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 0e2d027060..4212c58171 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -83,6 +83,23 @@ config ARM_SSBD
>
> If unsure, say Y.
>
> +config HARDEN_BRANCH_PREDICTOR
> + bool "Harden the branch predictor against aliasing attacks" if EXPERT = "y"
> + default y
> + help
> + Speculation attacks against some high-performance processors rely on
> + being able to manipulate the branch predictor for a victim context by
> + executing aliasing branches in the attacker context. Such attacks
> + can be partially mitigated against by clearing internal branch
> + predictor state and limiting the prediction logic in some situations.
> +
> + This config option will take CPU-specific actions to harden the
> + branch predictor against aliasing attacks and may rely on specific
> + instruction sequences or control bits being set by the system
> + firmware.
> +
> + If unsure, say Y.
> +
> endmenu
>
> menu "ARM errata workaround via the alternative framework"
> @@ -197,23 +214,6 @@ config ARM64_ERRATUM_834220
>
> endmenu
>
> -config HARDEN_BRANCH_PREDICTOR
> - bool "Harden the branch predictor against aliasing attacks" if EXPERT
> - default y
> - help
> - Speculation attacks against some high-performance processors rely on
> - being able to manipulate the branch predictor for a victim context by
> - executing aliasing branches in the attacker context. Such attacks
> - can be partially mitigated against by clearing internal branch
> - predictor state and limiting the prediction logic in some situations.
> -
> - This config option will take CPU-specific actions to harden the
> - branch predictor against aliasing attacks and may rely on specific
> - instruction sequences or control bits being set by the system
> - firmware.
> -
> - If unsure, say Y.
> -
> config ARM64_HARDEN_BRANCH_PREDICTOR
> def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
>
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (10 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features" Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 23:44 ` Stefano Stabellini
2018-05-22 17:42 ` [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head Julien Grall
2018-05-22 17:46 ` [for-4.11] Re: [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/include/asm-arm/smccc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index a6804cec99..74c13f8419 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -254,9 +254,9 @@ struct arm_smccc_res {
#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
- ARM_SMCCC_CONV_32, \
- ARM_SMCCC_OWNER_ARCH, \
- 0x8000)
+ ARM_SMCCC_CONV_32, \
+ ARM_SMCCC_OWNER_ARCH, \
+ 0x8000)
#define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID
2018-05-22 17:42 ` [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID Julien Grall
@ 2018-05-23 23:44 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 23:44 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/include/asm-arm/smccc.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index a6804cec99..74c13f8419 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -254,9 +254,9 @@ struct arm_smccc_res {
>
> #define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> - ARM_SMCCC_CONV_32, \
> - ARM_SMCCC_OWNER_ARCH, \
> - 0x8000)
> + ARM_SMCCC_CONV_32, \
> + ARM_SMCCC_OWNER_ARCH, \
> + 0x8000)
>
> #define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (11 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID Julien Grall
@ 2018-05-22 17:42 ` Julien Grall
2018-05-23 23:47 ` Stefano Stabellini
2018-05-22 17:46 ` [for-4.11] Re: [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:42 UTC (permalink / raw)
To: xen-devel; +Cc: andre.przywara, Julien Grall, sstabellini
Using current is fairly expensive, so save up into a variable.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
xen/arch/arm/traps.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 020b0b8eef..b1546f6907 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
{
if ( guest_mode(regs) )
{
+ struct vcpu *v = current;
+
/* If the guest has disabled the workaround, bring it back on. */
- if ( needs_ssbd_flip(current) )
+ if ( needs_ssbd_flip(v) )
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
/*
@@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
* but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
* (alias of HCR.VA) is cleared to 0."
*/
- if ( current->arch.hcr_el2 & HCR_VA )
- current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
+ if ( v->arch.hcr_el2 & HCR_VA )
+ v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
#ifdef CONFIG_NEW_VGIC
/*
@@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
* TODO: Investigate whether this is necessary to do on every
* trap and how it can be optimised.
*/
- vtimer_update_irqs(current);
- vcpu_update_evtchn_irq(current);
+ vtimer_update_irqs(v);
+ vcpu_update_evtchn_irq(v);
#endif
- vgic_sync_from_lrs(current);
+ vgic_sync_from_lrs(v);
}
}
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 62+ messages in thread* Re: [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head
2018-05-22 17:42 ` [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head Julien Grall
@ 2018-05-23 23:47 ` Stefano Stabellini
2018-05-24 10:29 ` Julien Grall
0 siblings, 1 reply; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-23 23:47 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, sstabellini, andre.przywara
On Tue, 22 May 2018, Julien Grall wrote:
> Using current is fairly expensive, so save up into a variable.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Good idea. I am curious to know actually how much this patch would save
but I am not going to ask you run the tests.
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/arch/arm/traps.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 020b0b8eef..b1546f6907 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
> {
> if ( guest_mode(regs) )
> {
> + struct vcpu *v = current;
> +
> /* If the guest has disabled the workaround, bring it back on. */
> - if ( needs_ssbd_flip(current) )
> + if ( needs_ssbd_flip(v) )
> arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
>
> /*
> @@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
> * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
> * (alias of HCR.VA) is cleared to 0."
> */
> - if ( current->arch.hcr_el2 & HCR_VA )
> - current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> + if ( v->arch.hcr_el2 & HCR_VA )
> + v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>
> #ifdef CONFIG_NEW_VGIC
> /*
> @@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
> * TODO: Investigate whether this is necessary to do on every
> * trap and how it can be optimised.
> */
> - vtimer_update_irqs(current);
> - vcpu_update_evtchn_irq(current);
> + vtimer_update_irqs(v);
> + vcpu_update_evtchn_irq(v);
> #endif
>
> - vgic_sync_from_lrs(current);
> + vgic_sync_from_lrs(v);
> }
> }
>
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head
2018-05-23 23:47 ` Stefano Stabellini
@ 2018-05-24 10:29 ` Julien Grall
2018-05-24 18:46 ` Stefano Stabellini
0 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-24 10:29 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, andre.przywara
Hi Stefano,
On 24/05/18 00:47, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
>> Using current is fairly expensive, so save up into a variable.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> Good idea. I am curious to know actually how much this patch would save
> but I am not going to ask you run the tests.
I haven't benchmark it but looked at the resulting assembly code. This
reduces by about ~20% the number of instructions in the function.
AFAIU, this is because of the way per-cpu access have been implemented.
The per-cpu offset is stored in a system register (TPIDR_EL2), all the
read to it cannot be optimized (access using volatile).
So every direct use of "current" will require at least a system register
access and then a load from memory.
Cheers,
>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>
>> ---
>> xen/arch/arm/traps.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 020b0b8eef..b1546f6907 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
>> {
>> if ( guest_mode(regs) )
>> {
>> + struct vcpu *v = current;
>> +
>> /* If the guest has disabled the workaround, bring it back on. */
>> - if ( needs_ssbd_flip(current) )
>> + if ( needs_ssbd_flip(v) )
>> arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
>>
>> /*
>> @@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
>> * but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
>> * (alias of HCR.VA) is cleared to 0."
>> */
>> - if ( current->arch.hcr_el2 & HCR_VA )
>> - current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>> + if ( v->arch.hcr_el2 & HCR_VA )
>> + v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>>
>> #ifdef CONFIG_NEW_VGIC
>> /*
>> @@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct cpu_user_regs *regs)
>> * TODO: Investigate whether this is necessary to do on every
>> * trap and how it can be optimised.
>> */
>> - vtimer_update_irqs(current);
>> - vcpu_update_evtchn_irq(current);
>> + vtimer_update_irqs(v);
>> + vcpu_update_evtchn_irq(v);
>> #endif
>>
>> - vgic_sync_from_lrs(current);
>> + vgic_sync_from_lrs(v);
>> }
>> }
>>
>> --
>> 2.11.0
>>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head
2018-05-24 10:29 ` Julien Grall
@ 2018-05-24 18:46 ` Stefano Stabellini
0 siblings, 0 replies; 62+ messages in thread
From: Stefano Stabellini @ 2018-05-24 18:46 UTC (permalink / raw)
To: Julien Grall; +Cc: xen-devel, Stefano Stabellini, andre.przywara
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 24/05/18 00:47, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > Using current is fairly expensive, so save up into a variable.
> > >
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> >
> > Good idea. I am curious to know actually how much this patch would save
> > but I am not going to ask you run the tests.
>
> I haven't benchmark it but looked at the resulting assembly code. This reduces
> by about ~20% the number of instructions in the function.
>
> AFAIU, this is because of the way per-cpu access have been implemented. The
> per-cpu offset is stored in a system register (TPIDR_EL2), all the read to it
> cannot be optimized (access using volatile).
>
> So every direct use of "current" will require at least a system register
> access and then a load from memory.
Very nice, thank you!
>
> >
> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> >
> > > ---
> > > xen/arch/arm/traps.c | 14 ++++++++------
> > > 1 file changed, 8 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 020b0b8eef..b1546f6907 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct
> > > cpu_user_regs *regs)
> > > {
> > > if ( guest_mode(regs) )
> > > {
> > > + struct vcpu *v = current;
> > > +
> > > /* If the guest has disabled the workaround, bring it back on.
> > > */
> > > - if ( needs_ssbd_flip(current) )
> > > + if ( needs_ssbd_flip(v) )
> > > arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
> > > /*
> > > @@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct
> > > cpu_user_regs *regs)
> > > * but the crucial bit is "On taking a vSError interrupt,
> > > HCR_EL2.VSE
> > > * (alias of HCR.VA) is cleared to 0."
> > > */
> > > - if ( current->arch.hcr_el2 & HCR_VA )
> > > - current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> > > + if ( v->arch.hcr_el2 & HCR_VA )
> > > + v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> > > #ifdef CONFIG_NEW_VGIC
> > > /*
> > > @@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct
> > > cpu_user_regs *regs)
> > > * TODO: Investigate whether this is necessary to do on every
> > > * trap and how it can be optimised.
> > > */
> > > - vtimer_update_irqs(current);
> > > - vcpu_update_evtchn_irq(current);
> > > + vtimer_update_irqs(v);
> > > + vcpu_update_evtchn_irq(v);
> > > #endif
> > > - vgic_sync_from_lrs(current);
> > > + vgic_sync_from_lrs(v);
> > > }
> > > }
> > >
> > > --
> > > 2.11.0
> > >
>
> --
> Julien Grall
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
* [for-4.11] Re: [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263)
2018-05-22 17:42 [PATCH 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263) Julien Grall
` (12 preceding siblings ...)
2018-05-22 17:42 ` [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head Julien Grall
@ 2018-05-22 17:46 ` Julien Grall
2018-05-23 4:07 ` Juergen Gross
13 siblings, 1 reply; 62+ messages in thread
From: Julien Grall @ 2018-05-22 17:46 UTC (permalink / raw)
To: xen-devel; +Cc: Juergen Gross, andre.przywara, sstabellini
I forgot to CC Juergen as RM. This series is candidate for Xen 4.11 as
part of XSA-263.
Cheers,
On 22/05/18 18:42, Julien Grall wrote:
> Hi all,
>
> This patch series implement the Xen hypervisor side of the "Spectre-v4"
> (CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable"
> (SSBD).
>
> More information can be found at:
> https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
>
> For all released Arm Cortex-A that are affected by this issue, then the
> preferred mitigation is simply to set a chicken bit in the firmware during
> CPU initialization and therefore no change to Xen is required. Other CPUs
> may require the chicken bit to be toggled dynamically (for example, when
> switching between kernel-mode and hypervisor-mode) and this is achieve by
> calling into EL3 via an SMC which has been published as part of the latest
> SMCCC specification:
> https://developer.arm.com/cache-speculation-vulnerability-firmware-specification
>
> as well as an ATF update for the released ARM cores affected by SSBD:
> https://github.com/ARM-software/arm-trusted-firmware/pull/1392
>
> These patches provide the following:
> 1. Safe probing of firmware to establish which CPUs in the system
> require calling into EL3 as part of the mitigation
> 2. A command-line option to force SSBD mitigation to be always on,
> always off, or dynamically toggled (default) for CPUs that require
> the EL3 call.
> 3. An initial implementation of the call via Xen, which exposes the
> mitigation to the guest via an HVC interface.
>
> This patch also provides bug fix and new infrastructure require to implement
> the mitigation:
> 1. Zeroed each vCPU stack
> 2. Provide generic assembly macros
> 3. Provide alternative callback (RFC)
>
> A branch can be found with all the patches at:
> https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
> branch ssbd/v1
>
> Cheers,
>
> Julien Grall (13):
> xen/arm: domain: Zeroed the vCPU stack
> xen/arm64: entry: Use named label in guest_sync
> xen/arm: setup: Check errata for boot CPU later on
> xen/arm: Add ARCH_WORKAROUND_2 probing
> xen/arm: Add command line option to control SSBD mitigation
> xen/arm: Add ARCH_WORKAROUND_2 support for guests
> xen/arm: Simplify alternative patching
> xen/arm: alternatives: Add dynamic patching feature
> xen/arm64: Add generic assembly macros
> xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
> xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture
> features"
> xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID
> xen/arm: Avoid to use current everywhere in enter_hypervisor_head
>
> docs/misc/xen-command-line.markdown | 18 +++++
> xen/arch/arm/Kconfig | 44 +++++++----
> xen/arch/arm/alternative.c | 79 +++++++++++--------
> xen/arch/arm/arm64/asm-offsets.c | 2 +
> xen/arch/arm/arm64/entry.S | 49 +++++++++++-
> xen/arch/arm/cpuerrata.c | 150 ++++++++++++++++++++++++++++++++++++
> xen/arch/arm/domain.c | 12 +++
> xen/arch/arm/setup.c | 8 +-
> xen/arch/arm/traps.c | 32 ++++++--
> xen/arch/arm/vsmc.c | 37 +++++++++
> xen/include/asm-arm/alternative.h | 44 +++++++++--
> xen/include/asm-arm/arm64/macros.h | 25 ++++++
> xen/include/asm-arm/cpuerrata.h | 42 ++++++++++
> xen/include/asm-arm/cpufeature.h | 3 +-
> xen/include/asm-arm/current.h | 6 +-
> xen/include/asm-arm/macros.h | 2 +-
> xen/include/asm-arm/smccc.h | 13 +++-
> 17 files changed, 495 insertions(+), 71 deletions(-)
> create mode 100644 xen/include/asm-arm/arm64/macros.h
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 62+ messages in thread