[PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tom Lendacky]

When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
at physical address 0x0. This causes mpf_base to be set to 0 and a
subsequent "if (!mpf_base)" check in default_get_smp_config() results in
the MP-table not being parsed.  Further into the boot this results in an
oops when attempting a read_apic_id().

Add a boolean variable that is set to true when the MP-table is found.
Use this variable for testing if the MP-table was found so that even a
value of 0 for mpf_base will result in continued parsing of the MP-table.

Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/kernel/mpparse.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 5cbb317..c3d3094 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -430,6 +430,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 }
 
 static unsigned long mpf_base;
+static bool mpf_found;
 
 static unsigned long __init get_mpc_size(unsigned long physptr)
 {
@@ -503,7 +504,7 @@ void __init default_get_smp_config(unsigned int early)
 	if (!smp_found_config)
 		return;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return;
 
 	if (acpi_lapic && early)
@@ -592,6 +593,7 @@ static int __init smp_scan_config(unsigned long base, unsigned long length)
 			smp_found_config = 1;
 #endif
 			mpf_base = base;
+			mpf_found = true;
 
 			pr_info("found SMP MP-table at [mem %#010lx-%#010lx] mapped at [%p]\n",
 				base, base + sizeof(*mpf) - 1, mpf);
@@ -857,7 +859,7 @@ static int __init update_mp_table(void)
 	if (!enable_update_mptable)
 		return 0;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return 0;
 
 	mpf = early_memremap(mpf_base, sizeof(*mpf));

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tom Lendacky]

On 11/6/2017 2:17 PM, Tom Lendacky wrote:
> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
> at physical address 0x0. This causes mpf_base to be set to 0 and a
> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
> the MP-table not being parsed.  Further into the boot this results in an
> oops when attempting a read_apic_id().
> 
> Add a boolean variable that is set to true when the MP-table is found.
> Use this variable for testing if the MP-table was found so that even a
> value of 0 for mpf_base will result in continued parsing of the MP-table.
> 
> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

I forgot to add a Fixes tag. If the patch is acceptable as is, let me know
if you would prefer another version with the Fixes tag or if you can add
it when merged:

Fixes: 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")

Thanks,
Tom

> ---
>   arch/x86/kernel/mpparse.c |    6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
> index 5cbb317..c3d3094 100644
> --- a/arch/x86/kernel/mpparse.c
> +++ b/arch/x86/kernel/mpparse.c
> @@ -430,6 +430,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
>   }
>   
>   static unsigned long mpf_base;
> +static bool mpf_found;
>   
>   static unsigned long __init get_mpc_size(unsigned long physptr)
>   {
> @@ -503,7 +504,7 @@ void __init default_get_smp_config(unsigned int early)
>   	if (!smp_found_config)
>   		return;
>   
> -	if (!mpf_base)
> +	if (!mpf_found)
>   		return;
>   
>   	if (acpi_lapic && early)
> @@ -592,6 +593,7 @@ static int __init smp_scan_config(unsigned long base, unsigned long length)
>   			smp_found_config = 1;
>   #endif
>   			mpf_base = base;
> +			mpf_found = true;
>   
>   			pr_info("found SMP MP-table at [mem %#010lx-%#010lx] mapped at [%p]\n",
>   				base, base + sizeof(*mpf) - 1, mpf);
> @@ -857,7 +859,7 @@ static int __init update_mp_table(void)
>   	if (!enable_update_mptable)
>   		return 0;
>   
> -	if (!mpf_base)
> +	if (!mpf_found)
>   		return 0;
>   
>   	mpf = early_memremap(mpf_base, sizeof(*mpf));
> 

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[H. Peter Anvin]

On 11/06/17 12:17, Tom Lendacky wrote:
> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
> at physical address 0x0. This causes mpf_base to be set to 0 and a
> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
> the MP-table not being parsed.  Further into the boot this results in an
> oops when attempting a read_apic_id().
> 
> Add a boolean variable that is set to true when the MP-table is found.
> Use this variable for testing if the MP-table was found so that even a
> value of 0 for mpf_base will result in continued parsing of the MP-table.
> 
> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>

Ahem... did anyone ever tell you that this is an epicly bad idea on your
part?  The low megabyte of physical memory has very special meaning on
x86, and deviating from the standard use of this memory is a *very*
dangerous thing to do, and imposing on the kernel a "fake null pointer"
requirement that exists only for the convenience of your particular
brokenness is not okay.

	-hpa

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tom Lendacky]

On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
> On 11/06/17 12:17, Tom Lendacky wrote:
>> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
>> at physical address 0x0. This causes mpf_base to be set to 0 and a
>> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
>> the MP-table not being parsed.  Further into the boot this results in an
>> oops when attempting a read_apic_id().
>>
>> Add a boolean variable that is set to true when the MP-table is found.
>> Use this variable for testing if the MP-table was found so that even a
>> value of 0 for mpf_base will result in continued parsing of the MP-table.
>>
>> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> 
> Ahem... did anyone ever tell you that this is an epicly bad idea on your
> part?  The low megabyte of physical memory has very special meaning on
> x86, and deviating from the standard use of this memory is a *very*
> dangerous thing to do, and imposing on the kernel a "fake null pointer"
> requirement that exists only for the convenience of your particular
> brokenness is not okay.
> 
> 	-hpa

That was my initial thought... what was something doing down at the start
of memory.  But when I looked at default_find_smp_config() it specifically
scans the bottom 1K for a an MP-table signature. I was hoping to get some
feedback as to whether this would really be an acceptable thing to do. So
I'm good with this patch being rejected, but the change I made in

5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")

does break something that was working before.

Thanks,
Tom

> 

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tom Lendacky]

On 11/6/2017 4:01 PM, Tom Lendacky wrote:
> On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
>> On 11/06/17 12:17, Tom Lendacky wrote:
>>> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
>>> at physical address 0x0. This causes mpf_base to be set to 0 and a
>>> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
>>> the MP-table not being parsed.  Further into the boot this results in an
>>> oops when attempting a read_apic_id().
>>>
>>> Add a boolean variable that is set to true when the MP-table is found.
>>> Use this variable for testing if the MP-table was found so that even a
>>> value of 0 for mpf_base will result in continued parsing of the MP-table.
>>>
>>> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>
>> Ahem... did anyone ever tell you that this is an epicly bad idea on your
>> part?  The low megabyte of physical memory has very special meaning on
>> x86, and deviating from the standard use of this memory is a *very*
>> dangerous thing to do, and imposing on the kernel a "fake null pointer"
>> requirement that exists only for the convenience of your particular
>> brokenness is not okay.
>>
>>     -hpa
> 
> That was my initial thought... what was something doing down at the start
> of memory.  But when I looked at default_find_smp_config() it specifically
> scans the bottom 1K for a an MP-table signature. I was hoping to get some
> feedback as to whether this would really be an acceptable thing to do. So
> I'm good with this patch being rejected, but the change I made in
> 
> 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
> 
> does break something that was working before.

Btw, it was working before because instead of saving off the physical
address as 5997efb96756 now does, it saved off a virtual address that
pointed to physical address 0 (0xffff880000000000) and used that in the
conditional.

Thanks,
Tom


> 
> Thanks,
> Tom
> 
>>

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Borislav Petkov]

On Mon, Nov 06, 2017 at 05:00:31PM -0600, Tom Lendacky wrote:
> Btw, it was working before because instead of saving off the physical
> address as 5997efb96756 now does, it saved off a virtual address that
> pointed to physical address 0 (0xffff880000000000) and used that in the
> conditional.

Dunno, should we support any braindead vm implementation which puts
stuff in the low megabyte?

I mean, the fix is simple enough and we probably don't care all that
much whatever potent sh*t people are smoking as long as it is all the
same to the kernel...

IMO.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tomeu Vizoso]

On 6 November 2017 at 23:01, Tom Lendacky <thomas.lendacky@amd.com> wrote:
> On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
>>
>> On 11/06/17 12:17, Tom Lendacky wrote:
>>>
>>> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
>>> at physical address 0x0. This causes mpf_base to be set to 0 and a
>>> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
>>> the MP-table not being parsed.  Further into the boot this results in an
>>> oops when attempting a read_apic_id().
>>>
>>> Add a boolean variable that is set to true when the MP-table is found.
>>> Use this variable for testing if the MP-table was found so that even a
>>> value of 0 for mpf_base will result in continued parsing of the MP-table.
>>>
>>> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>
>>
>> Ahem... did anyone ever tell you that this is an epicly bad idea on your
>> part?  The low megabyte of physical memory has very special meaning on
>> x86, and deviating from the standard use of this memory is a *very*
>> dangerous thing to do, and imposing on the kernel a "fake null pointer"
>> requirement that exists only for the convenience of your particular
>> brokenness is not okay.
>>
>>         -hpa
>
>
> That was my initial thought... what was something doing down at the start
> of memory.  But when I looked at default_find_smp_config() it specifically
> scans the bottom 1K for a an MP-table signature. I was hoping to get some
> feedback as to whether this would really be an acceptable thing to do. So
> I'm good with this patch being rejected, but the change I made in
>
> 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
>
> does break something that was working before.

Do I understand correctly that the best we can do right now is
reverting 5997efb96756?

Thanks,

Tomeu

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tomeu Vizoso]

Adding regression@leemhuis.info to CC so this regression is tracked.

Regards,

Tomeu

On 8 November 2017 at 09:37, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
> On 6 November 2017 at 23:01, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>> On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
>>>
>>> On 11/06/17 12:17, Tom Lendacky wrote:
>>>>
>>>> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
>>>> at physical address 0x0. This causes mpf_base to be set to 0 and a
>>>> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
>>>> the MP-table not being parsed.  Further into the boot this results in an
>>>> oops when attempting a read_apic_id().
>>>>
>>>> Add a boolean variable that is set to true when the MP-table is found.
>>>> Use this variable for testing if the MP-table was found so that even a
>>>> value of 0 for mpf_base will result in continued parsing of the MP-table.
>>>>
>>>> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>
>>>
>>> Ahem... did anyone ever tell you that this is an epicly bad idea on your
>>> part?  The low megabyte of physical memory has very special meaning on
>>> x86, and deviating from the standard use of this memory is a *very*
>>> dangerous thing to do, and imposing on the kernel a "fake null pointer"
>>> requirement that exists only for the convenience of your particular
>>> brokenness is not okay.
>>>
>>>         -hpa
>>
>>
>> That was my initial thought... what was something doing down at the start
>> of memory.  But when I looked at default_find_smp_config() it specifically
>> scans the bottom 1K for a an MP-table signature. I was hoping to get some
>> feedback as to whether this would really be an acceptable thing to do. So
>> I'm good with this patch being rejected, but the change I made in
>>
>> 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
>>
>> does break something that was working before.
>
> Do I understand correctly that the best we can do right now is
> reverting 5997efb96756?
>
> Thanks,
>
> Tomeu

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Tomeu Vizoso]

And now with the correct email.

Sorry about that,

Tomeu

On 16 November 2017 at 10:16, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
> Adding regression@leemhuis.info to CC so this regression is tracked.
>
> Regards,
>
> Tomeu
>
> On 8 November 2017 at 09:37, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote:
>> On 6 November 2017 at 23:01, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>>> On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
>>>>
>>>> On 11/06/17 12:17, Tom Lendacky wrote:
>>>>>
>>>>> When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
>>>>> at physical address 0x0. This causes mpf_base to be set to 0 and a
>>>>> subsequent "if (!mpf_base)" check in default_get_smp_config() results in
>>>>> the MP-table not being parsed.  Further into the boot this results in an
>>>>> oops when attempting a read_apic_id().
>>>>>
>>>>> Add a boolean variable that is set to true when the MP-table is found.
>>>>> Use this variable for testing if the MP-table was found so that even a
>>>>> value of 0 for mpf_base will result in continued parsing of the MP-table.
>>>>>
>>>>> Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>>>>
>>>>
>>>> Ahem... did anyone ever tell you that this is an epicly bad idea on your
>>>> part?  The low megabyte of physical memory has very special meaning on
>>>> x86, and deviating from the standard use of this memory is a *very*
>>>> dangerous thing to do, and imposing on the kernel a "fake null pointer"
>>>> requirement that exists only for the convenience of your particular
>>>> brokenness is not okay.
>>>>
>>>>         -hpa
>>>
>>>
>>> That was my initial thought... what was something doing down at the start
>>> of memory.  But when I looked at default_find_smp_config() it specifically
>>> scans the bottom 1K for a an MP-table signature. I was hoping to get some
>>> feedback as to whether this would really be an acceptable thing to do. So
>>> I'm good with this patch being rejected, but the change I made in
>>>
>>> 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
>>>
>>> does break something that was working before.
>>
>> Do I understand correctly that the best we can do right now is
>> reverting 5997efb96756?
>>
>> Thanks,
>>
>> Tomeu

Re: [PATCH] x86/boot: Fix boot failure when SMP MP-table is based at 0

[Thomas Gleixner]

On Mon, 6 Nov 2017, Tom Lendacky wrote:
> On 11/6/2017 3:41 PM, H. Peter Anvin wrote:
> > On 11/06/17 12:17, Tom Lendacky wrote:
> > > When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
> > > at physical address 0x0. This causes mpf_base to be set to 0 and a
> > > subsequent "if (!mpf_base)" check in default_get_smp_config() results in
> > > the MP-table not being parsed.  Further into the boot this results in an
> > > oops when attempting a read_apic_id().
> > > 
> > > Add a boolean variable that is set to true when the MP-table is found.
> > > Use this variable for testing if the MP-table was found so that even a
> > > value of 0 for mpf_base will result in continued parsing of the MP-table.
> > > 
> > > Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
> > > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> > 
> > Ahem... did anyone ever tell you that this is an epicly bad idea on your
> > part?  The low megabyte of physical memory has very special meaning on
> > x86, and deviating from the standard use of this memory is a *very*
> > dangerous thing to do, and imposing on the kernel a "fake null pointer"
> > requirement that exists only for the convenience of your particular
> > brokenness is not okay.
> > 
> > 	-hpa
> 
> That was my initial thought... what was something doing down at the start
> of memory.  But when I looked at default_find_smp_config() it specifically
> scans the bottom 1K for a an MP-table signature. I was hoping to get some
> feedback as to whether this would really be an acceptable thing to do. So
> I'm good with this patch being rejected, but the change I made in
> 
> 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
> 
> does break something that was working before.

This goes back to Linux 1.1.x

/*
 * Physical page 0 is special; it's not touched by Linux since BIOS
 * and SMM (for laptops with [34]86/SL chips) may need it.  It is read
 * and write protected to detect null pointer references in the
 * kernel.
 * It may also hold the MP configuration table when we are booting SMP.
 */

and then got changed in 2.3.40 to:

	/*
	 * FIXME: Linux assumes you have 640K of base ram..
	 * this continues the error...
	 *
	 * 1) Scan the bottom 1K for a signature
	 * 2) Scan the top 1K of base RAM
	 * 3) Scan the 64K of bios
	 */
	if (smp_scan_config(0x0, 0x400) ||
	    smp_scan_config(639 * 0x400, 0x400) ||
	    smp_scan_config(0xF0000, 0x10000))
		return;

which is what we still have completely unmodified.

What hpa considers to be epic fail was added 20+ years ago and probably
with a reason. We carried that along forever and now someone looked for a
place to stick MP config in for his VM thingy and picked the first place
which is checked. Not a big surprise.

So we are stuck with it, whether we like it or not.

Thanks,

	tglx

[tip:x86/urgent] x86/boot: Fix boot failure when SMP MP-table is based at 0

[tip-bot for Tom Lendacky]

Commit-ID:  ac5292e9a294618cecb31109d1ba265e3d027ba2
Gitweb:     https://git.kernel.org/tip/ac5292e9a294618cecb31109d1ba265e3d027ba2
Author:     Tom Lendacky <thomas.lendacky@amd.com>
AuthorDate: Mon, 6 Nov 2017 14:17:53 -0600
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 17 Nov 2017 15:30:33 +0100

x86/boot: Fix boot failure when SMP MP-table is based at 0

When crosvm is used to boot a kernel as a VM, the SMP MP-table is found
at physical address 0x0. This causes mpf_base to be set to 0 and a
subsequent "if (!mpf_base)" check in default_get_smp_config() results in
the MP-table not being parsed.  Further into the boot this results in an
oops when attempting a read_apic_id().

Add a boolean variable that is set to true when the MP-table is found.
Use this variable for testing if the MP-table was found so that even a
value of 0 for mpf_base will result in continued parsing of the MP-table.

Fixes: 5997efb96756 ("x86/boot: Use memremap() to map the MPF and MPC data")
Reported-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: regression@leemhuis.info
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20171106201753.23059.86674.stgit@tlendack-t1.amdoffice.net

---
 arch/x86/kernel/mpparse.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 410c5da..3a4b128 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -431,6 +431,7 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type)
 }
 
 static unsigned long mpf_base;
+static bool mpf_found;
 
 static unsigned long __init get_mpc_size(unsigned long physptr)
 {
@@ -504,7 +505,7 @@ void __init default_get_smp_config(unsigned int early)
 	if (!smp_found_config)
 		return;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return;
 
 	if (acpi_lapic && early)
@@ -593,6 +594,7 @@ static int __init smp_scan_config(unsigned long base, unsigned long length)
 			smp_found_config = 1;
 #endif
 			mpf_base = base;
+			mpf_found = true;
 
 			pr_info("found SMP MP-table at [mem %#010lx-%#010lx] mapped at [%p]\n",
 				base, base + sizeof(*mpf) - 1, mpf);
@@ -858,7 +860,7 @@ static int __init update_mp_table(void)
 	if (!enable_update_mptable)
 		return 0;
 
-	if (!mpf_base)
+	if (!mpf_found)
 		return 0;
 
 	mpf = early_memremap(mpf_base, sizeof(*mpf));