[PATCH] x86, microcode: Don't initialize microcode code on paravirt

[PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Boris Ostrovsky]

Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.

In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()->load_ucode_ap()
->check_loader_disabled_ap())

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 arch/x86/kernel/cpu/microcode/core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 2ce9051..ebd232d 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -557,7 +557,7 @@ static int __init microcode_init(void)
 	struct cpuinfo_x86 *c = &cpu_data(0);
 	int error;
 
-	if (dis_ucode_ldr)
+	if (paravirt_enabled() || dis_ucode_ldr)
 		return 0;
 
 	if (c->x86_vendor == X86_VENDOR_INTEL)
-- 
1.7.1

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Konrad Rzeszutek Wilk]

On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
> Paravirtual guests are not expected to load microcode into processors
> and therefore it is not necessary to initialize microcode loading
> logic.

CC-ing the KVM folks since they use the paravirt interface too.
> 
> In fact, under certain circumstances initializing this logic may cause
> the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
> macro which does not work in Xen (the code path that leads to this macro
> happens during resume when we call mc_bp_resume()->load_ucode_ap()
> ->check_loader_disabled_ap())
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/kernel/cpu/microcode/core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> index 2ce9051..ebd232d 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -557,7 +557,7 @@ static int __init microcode_init(void)
>  	struct cpuinfo_x86 *c = &cpu_data(0);
>  	int error;
>  
> -	if (dis_ucode_ldr)
> +	if (paravirt_enabled() || dis_ucode_ldr)
>  		return 0;
>  
>  	if (c->x86_vendor == X86_VENDOR_INTEL)
> -- 
> 1.7.1
> 

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Paolo Bonzini]

On 01/12/2014 22:57, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
>> Paravirtual guests are not expected to load microcode into processors
>> and therefore it is not necessary to initialize microcode loading
>> logic.
> 
> CC-ing the KVM folks since they use the paravirt interface too.

We also do not want to load microcode. :)  Thanks for the heads-up.

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

>> In fact, under certain circumstances initializing this logic may cause
>> the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
>> macro which does not work in Xen (the code path that leads to this macro
>> happens during resume when we call mc_bp_resume()->load_ucode_ap()
>> ->check_loader_disabled_ap())
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>  arch/x86/kernel/cpu/microcode/core.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
>> index 2ce9051..ebd232d 100644
>> --- a/arch/x86/kernel/cpu/microcode/core.c
>> +++ b/arch/x86/kernel/cpu/microcode/core.c
>> @@ -557,7 +557,7 @@ static int __init microcode_init(void)
>>  	struct cpuinfo_x86 *c = &cpu_data(0);
>>  	int error;
>>  
>> -	if (dis_ucode_ldr)
>> +	if (paravirt_enabled() || dis_ucode_ldr)
>>  		return 0;
>>  
>>  	if (c->x86_vendor == X86_VENDOR_INTEL)
>> -- 
>> 1.7.1
>>

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Borislav Petkov]

On Mon, Dec 01, 2014 at 11:12:38PM +0100, Paolo Bonzini wrote:
> We also do not want to load microcode. :)  Thanks for the heads-up.

You don't need to :P

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Borislav Petkov]

On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
> Paravirtual guests are not expected to load microcode into processors
> and therefore it is not necessary to initialize microcode loading
> logic.
> 
> In fact, under certain circumstances initializing this logic may cause
> the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
> macro which does not work in Xen (the code path that leads to this macro
> happens during resume when we call mc_bp_resume()->load_ucode_ap()
> ->check_loader_disabled_ap())
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/kernel/cpu/microcode/core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> index 2ce9051..ebd232d 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -557,7 +557,7 @@ static int __init microcode_init(void)
>  	struct cpuinfo_x86 *c = &cpu_data(0);
>  	int error;
>  
> -	if (dis_ucode_ldr)
> +	if (paravirt_enabled() || dis_ucode_ldr)

Ok, let me make sure I understand this correctly: The early path doesn't
get executed on paravirt, i.e. the path along load_ucode_intel_ap()?

And you want to avoid loading of the microcode driver because the only
path we come to load_ucode_ap() on paravirt is the hotplug notifier?

Btw, we've applied another fix today for 3.18 final which limits the
microcode reloading to 64-bit only:

http://git.kernel.org/tip/02ecc41abcea4ff9291d548f6f846b29b354ddd2

which should accidentally fix the paravirt issue too, no?

Because if so, I'd like to delay your patch for the 3.19 merge window
unless absolutely necessary.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Boris Ostrovsky]

On 12/01/2014 05:00 PM, Borislav Petkov wrote:
> On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
>> Paravirtual guests are not expected to load microcode into processors
>> and therefore it is not necessary to initialize microcode loading
>> logic.
>>
>> In fact, under certain circumstances initializing this logic may cause
>> the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
>> macro which does not work in Xen (the code path that leads to this macro
>> happens during resume when we call mc_bp_resume()->load_ucode_ap()
>> ->check_loader_disabled_ap())
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> ---
>>   arch/x86/kernel/cpu/microcode/core.c |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
>> index 2ce9051..ebd232d 100644
>> --- a/arch/x86/kernel/cpu/microcode/core.c
>> +++ b/arch/x86/kernel/cpu/microcode/core.c
>> @@ -557,7 +557,7 @@ static int __init microcode_init(void)
>>   	struct cpuinfo_x86 *c = &cpu_data(0);
>>   	int error;
>>   
>> -	if (dis_ucode_ldr)
>> +	if (paravirt_enabled() || dis_ucode_ldr)
> Ok, let me make sure I understand this correctly: The early path doesn't
> get executed on paravirt, i.e. the path along load_ucode_intel_ap()?

(+KVM folks here as well)

Xen PV doesn't start with startup_32()/startup_32_smp() so for Xen this 
is true. Don't know about KVM (or lguest).

>
> And you want to avoid loading of the microcode driver because the only
> path we come to load_ucode_ap() on paravirt is the hotplug notifier?

That's my understanding, yes.

>
> Btw, we've applied another fix today for 3.18 final which limits the
> microcode reloading to 64-bit only:
>
> http://git.kernel.org/tip/02ecc41abcea4ff9291d548f6f846b29b354ddd2
>
> which should accidentally fix the paravirt issue too, no?

I think so. The problem we have now is __pa() macro that we only use on 
32-bit. I'll queue this for overnight tests to make sure and if it 
indeed works then 3.19 should be fine.

Thanks.
-boris

>
> Because if so, I'd like to delay your patch for the 3.19 merge window
> unless absolutely necessary.
>
> Thanks.
>

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Borislav Petkov]

On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote:
> I think so. The problem we have now is __pa() macro that we only use
> on 32-bit. I'll queue this for overnight tests to make sure and if it
> indeed works then 3.19 should be fine.

Cool, thanks.

I'd still take your patch for 3.19 though because I'm fixing the 32-bit
reloading path properly and will remove the ifdef afterwards.

And even then, I'd like to prevent loading the module on a paravirt
guest if it is totally unneeded there.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Boris Ostrovsky]

On 12/01/2014 05:37 PM, Borislav Petkov wrote:
> On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote:
>> I think so. The problem we have now is __pa() macro that we only use
>> on 32-bit. I'll queue this for overnight tests to make sure and if it
>> indeed works then 3.19 should be fine.
> Cool, thanks.

All tests passed.

> I'd still take your patch for 3.19 though because I'm fixing the 32-bit
> reloading path properly and will remove the ifdef afterwards.
>
> And even then, I'd like to prevent loading the module on a paravirt
> guest if it is totally unneeded there.
>

I wonder whether we should prevent all guests (not just paravirt) from 
loading microcode driver (and from doing early microcode loading).

-boris

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Borislav Petkov]

On Tue, Dec 02, 2014 at 09:36:40AM -0500, Boris Ostrovsky wrote:
> All tests passed.

Thanks!

> I wonder whether we should prevent all guests (not just paravirt) from
> loading microcode driver (and from doing early microcode loading).

I don't think the unmodified ones need to. At least I haven't seen any
issues so far.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.

Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt

[Greg KH]

On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
> Paravirtual guests are not expected to load microcode into processors
> and therefore it is not necessary to initialize microcode loading
> logic.
> 
> In fact, under certain circumstances initializing this logic may cause
> the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
> macro which does not work in Xen (the code path that leads to this macro
> happens during resume when we call mc_bp_resume()->load_ucode_ap()
> ->check_loader_disabled_ap())
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
>  arch/x86/kernel/cpu/microcode/core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>

[tip:x86/microcode] x86, microcode: Don' t initialize microcode code on paravirt

[tip-bot for Boris Ostrovsky]

Commit-ID:  a18a0f6850d4b286a5ebf02cd5b22fe496b86349
Gitweb:     http://git.kernel.org/tip/a18a0f6850d4b286a5ebf02cd5b22fe496b86349
Author:     Boris Ostrovsky <boris.ostrovsky@oracle.com>
AuthorDate: Mon, 1 Dec 2014 16:27:44 -0500
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Sat, 6 Dec 2014 12:59:03 +0100

x86, microcode: Don't initialize microcode code on paravirt

Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.

In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()->load_ucode_ap()
->check_loader_disabled_ap())

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrovsky@oracle.com
Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/kernel/cpu/microcode/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 2ce9051..ebd232d 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -557,7 +557,7 @@ static int __init microcode_init(void)
 	struct cpuinfo_x86 *c = &cpu_data(0);
 	int error;
 
-	if (dis_ucode_ldr)
+	if (paravirt_enabled() || dis_ucode_ldr)
 		return 0;
 
 	if (c->x86_vendor == X86_VENDOR_INTEL)