[GIT PULL] x86/urgent for v5.13-rc5

[GIT PULL] x86/urgent for v5.13-rc5

[Borislav Petkov]

Hi Linus,

a bunch of x86/urgent stuff accumulated for the last two weeks so lemme
unload it to you. It should be all totally risk-free, ofcourse. :-)

Please pull,
thx.

---

The following changes since commit c4681547bcce777daf576925a966ffa824edd09d:

  Linux 5.13-rc3 (2021-05-23 11:42:48 -1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v5.13-rc5

for you to fetch changes up to 009767dbf42ac0dbe3cf48c1ee224f6b778aa85a:

  x86/sev: Check SME/SEV support in CPUID first (2021-06-04 18:39:09 +0200)

----------------------------------------------------------------
- Fix out-of-spec hardware (1st gen Hygon) which does not implement
MSR_AMD64_SEV even though the spec clearly states so, and check CPUID
bits first.

- Send only one signal to a task when it is a SEGV_PKUERR si_code type.

- Do away with all the wankery of reserving X amount of memory in
the first megabyte to prevent BIOS corrupting it and simply and
unconditionally reserve the whole first megabyte.

- Make alternatives NOP optimization work at an arbitrary position
within the patched sequence because the compiler can put single-byte
NOPs for alignment anywhere in the sequence (32-bit retpoline), vs our
previous assumption that the NOPs are only appended.

- Force-disable ENQCMD[S] instructions support and remove update_pasid()
because of insufficient protection against FPU state modification in an
interrupt context, among other xstate horrors which are being addressed
at the moment. This one limits the fallout until proper enablement.

- Use cpu_feature_enabled() in the idxd driver so that it can be
build-time disabled through the defines in .../asm/disabled-features.h.

- Fix LVT thermal setup for SMI delivery mode by making sure the APIC
LVT value is read before APIC initialization so that softlockups during
boot do not happen at least on one machine.

- Mark all legacy interrupts as legacy vectors when the IO-APIC is
disabled and when all legacy interrupts are routed through the PIC.

----------------------------------------------------------------
Borislav Petkov (3):
      x86/thermal: Fix LVT thermal setup for SMI delivery mode
      dmaengine: idxd: Use cpu_feature_enabled()
      x86/alternative: Optimize single-byte NOPs at an arbitrary position

Jiashuo Liang (1):
      x86/fault: Don't send SIGSEGV twice on SEGV_PKUERR

Mike Rapoport (1):
      x86/setup: Always reserve the first 1M of RAM

Pu Wen (1):
      x86/sev: Check SME/SEV support in CPUID first

Thomas Gleixner (2):
      x86/apic: Mark _all_ legacy interrupts when IO/APIC is missing
      x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()

 arch/x86/include/asm/apic.h              |  1 +
 arch/x86/include/asm/disabled-features.h |  7 +---
 arch/x86/include/asm/fpu/api.h           |  6 +--
 arch/x86/include/asm/fpu/internal.h      |  7 ----
 arch/x86/include/asm/thermal.h           |  4 +-
 arch/x86/kernel/alternative.c            | 64 +++++++++++++++++++++++---------
 arch/x86/kernel/apic/apic.c              |  1 +
 arch/x86/kernel/apic/vector.c            | 20 ++++++++++
 arch/x86/kernel/fpu/xstate.c             | 57 ----------------------------
 arch/x86/kernel/setup.c                  | 44 +++++++++++++++-------
 arch/x86/mm/fault.c                      |  4 +-
 arch/x86/mm/mem_encrypt_identity.c       | 11 +++---
 arch/x86/platform/efi/quirks.c           | 12 ++++++
 arch/x86/realmode/init.c                 | 14 ++++---
 drivers/dma/idxd/init.c                  |  4 +-
 drivers/thermal/intel/therm_throt.c      | 15 ++++++--
 16 files changed, 145 insertions(+), 126 deletions(-)

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Linus Torvalds]

On Sun, Jun 6, 2021 at 12:55 AM Borislav Petkov <bp@suse.de> wrote:
>
> - Do away with all the wankery of reserving X amount of memory in
> the first megabyte to prevent BIOS corrupting it and simply and
> unconditionally reserve the whole first megabyte.

This seems a bit draconic.

How does this work at all under Windows? There must be some windows
knowledge about what the BIOS updates that we're not aware of.

I've pulled it, but it does seem like something odd is going on.

And that

    Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")

makes me go "Umm.." too. What did a799c2bd29d1 actually break? It
looks like it was meant to be a no-op consolidation - if somebody
bisected to it, I think that is a sign that there's something odd
there.

           Linus

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Mike Rapoport]

On Sun, Jun 06, 2021 at 12:38:32PM -0700, Linus Torvalds wrote:
> On Sun, Jun 6, 2021 at 12:55 AM Borislav Petkov <bp@suse.de> wrote:
> >
> > - Do away with all the wankery of reserving X amount of memory in
> > the first megabyte to prevent BIOS corrupting it and simply and
> > unconditionally reserve the whole first megabyte.
> 
> This seems a bit draconic.
> 
> How does this work at all under Windows? There must be some windows
> knowledge about what the BIOS updates that we're not aware of.

A while ago hpa said:

	As far as I know, Windows 7 actually reserves all memory below
	1 MiB to avoid BIOS bugs.

(https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2)
 
> I've pulled it, but it does seem like something odd is going on.
> 
> And that
> 
>     Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> 
> makes me go "Umm.." too. What did a799c2bd29d1 actually break? It
> looks like it was meant to be a no-op consolidation - if somebody
> bisected to it, I think that is a sign that there's something odd
> there.
 
I also hoped that a799c2bd29d1 would be a no-op consolidation, but I
overlooked that if a user sets CONFIG_X86_RESERVE_LOW or reservelow to 640K
instead of the default 64K, we end up reserving all the memory below 1M
before we allocate the real mode trampoline. This gets even more hairy
because of other things that may also need to reserve the entire first
megabyte, like crash kernel or workaround for Sandy Bridge integrated
graphics bugs.

I believe that reserving everything below 1M after the real mode trampoline
is allocated reduces amount of hidden dependencies and makes things simpler
overall.

-- 
Sincerely yours,
Mike.

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Linus Torvalds]

On Sun, Jun 6, 2021 at 1:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> A while ago hpa said:
>
>         As far as I know, Windows 7 actually reserves all memory below
>         1 MiB to avoid BIOS bugs.
>
> (https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2)

It would be good to have that checked somehow.

I don't think this matters on any machine with gigs of RAM, but I do
wonder about the people who want to do small configurations. Maybe
they've given up on x86?

It also eats into that somewhat precious legacy DMA resource and eats
up a fair chunk of that. Again, not an issue on modern hardware, but
..

> I believe that reserving everything below 1M after the real mode trampoline
> is allocated reduces amount of hidden dependencies and makes things simpler
> overall.

Simpler, perhaps, and _I_ personally don't care about about 512kB of
memory any more on any machines I have, but ..

          Linus

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Borislav Petkov]

On Sun, Jun 06, 2021 at 02:23:21PM -0700, Linus Torvalds wrote:
> On Sun, Jun 6, 2021 at 1:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > A while ago hpa said:
> >
> >         As far as I know, Windows 7 actually reserves all memory below
> >         1 MiB to avoid BIOS bugs.
> >
> > (https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2)
> 
> It would be good to have that checked somehow.
> 
> I don't think this matters on any machine with gigs of RAM, but I do
> wonder about the people who want to do small configurations. Maybe
> they've given up on x86?
> 
> It also eats into that somewhat precious legacy DMA resource and eats
> up a fair chunk of that. Again, not an issue on modern hardware, but
> ..
> 
> > I believe that reserving everything below 1M after the real mode trampoline
> > is allocated reduces amount of hidden dependencies and makes things simpler
> > overall.
> 
> Simpler, perhaps, and _I_ personally don't care about about 512kB of
> memory any more on any machines I have, but ..

Let's see if Sasha can dig out something... CCed.

@Sasha, can you figure out who we can talk to whether Windoze reserves
the first megabyte of memory unconditionally?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Sasha Levin]

On Mon, Jun 07, 2021 at 12:07:58AM +0200, Borislav Petkov wrote:
>On Sun, Jun 06, 2021 at 02:23:21PM -0700, Linus Torvalds wrote:
>> On Sun, Jun 6, 2021 at 1:58 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>> >
>> > A while ago hpa said:
>> >
>> >         As far as I know, Windows 7 actually reserves all memory below
>> >         1 MiB to avoid BIOS bugs.
>> >
>> > (https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2)
>>
>> It would be good to have that checked somehow.
>>
>> I don't think this matters on any machine with gigs of RAM, but I do
>> wonder about the people who want to do small configurations. Maybe
>> they've given up on x86?
>>
>> It also eats into that somewhat precious legacy DMA resource and eats
>> up a fair chunk of that. Again, not an issue on modern hardware, but
>> ..
>>
>> > I believe that reserving everything below 1M after the real mode trampoline
>> > is allocated reduces amount of hidden dependencies and makes things simpler
>> > overall.
>>
>> Simpler, perhaps, and _I_ personally don't care about about 512kB of
>> memory any more on any machines I have, but ..
>
>Let's see if Sasha can dig out something... CCed.
>
>@Sasha, can you figure out who we can talk to whether Windoze reserves
>the first megabyte of memory unconditionally?

That's a great question, but I can't help there anymore :)

Adding James Morris...

-- 
Thanks,
Sasha

Re: [GIT PULL] x86/urgent for v5.13-rc5

[James Morris]

On Sun, 6 Jun 2021, Sasha Levin wrote:

> >
> >Let's see if Sasha can dig out something... CCed.
> >
> >@Sasha, can you figure out who we can talk to whether Windoze reserves
> >the first megabyte of memory unconditionally?
> 
> That's a great question, but I can't help there anymore :)
> 
> Adding James Morris...

Adding Michael Kelley.


-- 
James Morris
<jmorris@namei.org>

RE: [GIT PULL] x86/urgent for v5.13-rc5

[Michael Kelley]

From: James Morris <jmorris@namei.org> Sent: Monday, June 7, 2021 11:47 AM
> 
> On Sun, 6 Jun 2021, Sasha Levin wrote:
> 
> > >
> > >Let's see if Sasha can dig out something... CCed.
> > >
> > >@Sasha, can you figure out who we can talk to whether Windoze reserves
> > >the first megabyte of memory unconditionally?
> >
> > That's a great question, but I can't help there anymore :)
> >
> > Adding James Morris...
> 
> Adding Michael Kelley.
> 

I checked with the Windows team.  Peter Anvin's statement from 11
years ago is true.  On Intel and AMD processors, Windows unconditionally
reserves the 1st megabyte of memory, minus one page used for real
mode startup.   This is done to work around BIOS bugs.

Michael

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Borislav Petkov]

On Tue, Jun 08, 2021 at 05:53:15PM +0000, Michael Kelley wrote:
> I checked with the Windows team.  Peter Anvin's statement from 11
> years ago is true.  On Intel and AMD processors, Windows unconditionally
> reserves the 1st megabyte of memory, minus one page used for real
> mode startup.   This is done to work around BIOS bugs.

Thanks for checking!

I guess us doing the same is probably fine.

Linus, maybe we should at least give it a try and see whether someone
complains and revert, potentially...?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Linus Torvalds]

On Tue, Jun 8, 2021 at 11:33 AM Borislav Petkov <bp@alien8.de> wrote:
>
> Linus, maybe we should at least give it a try and see whether someone
> complains and revert, potentially...?

I already merged the change that did that.

It might be worth adding a comment about the verified Windows behavior
here, but I think otherwise we're all done.

Unless somebody complains, as you say.

            Linus

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Borislav Petkov]

On Tue, Jun 08, 2021 at 12:22:50PM -0700, Linus Torvalds wrote:
> On Tue, Jun 8, 2021 at 11:33 AM Borislav Petkov <bp@alien8.de> wrote:
> >
> > Linus, maybe we should at least give it a try and see whether someone
> > complains and revert, potentially...?
> 
> I already merged the change that did that.

Oh yeah, I meant: let's leave it in and try it and only revert if there's
trouble.

> It might be worth adding a comment about the verified Windows behavior
> here, but I think otherwise we're all done.

How's that (comment re-flowed):

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1e720626069a..b58cdc70f86b 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1084,17 +1084,18 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	/*
-	 * Find free memory for the real mode trampoline and place it
-	 * there.
-	 * If there is not enough free memory under 1M, on EFI-enabled
-	 * systems there will be additional attempt to reclaim the memory
-	 * for the real mode trampoline at efi_free_boot_services().
+	 * Find free memory for the real mode trampoline and place it there. If
+	 * there is not enough free memory under 1M, on EFI-enabled systems
+	 * there will be additional attempt to reclaim the memory for the real
+	 * mode trampoline at efi_free_boot_services().
 	 *
-	 * Unconditionally reserve the entire first 1M of RAM because
-	 * BIOSes are know to corrupt low memory and several
-	 * hundred kilobytes are not worth complex detection what memory gets
-	 * clobbered. Moreover, on machines with SandyBridge graphics or in
-	 * setups that use crashkernel the entire 1M is reserved anyway.
+	 * Unconditionally reserve the entire first 1M of RAM because BIOSes
+	 * are known to corrupt low memory and several hundred kilobytes are not
+	 * worth complex detection what memory gets clobbered. Windows does the
+	 * same thing for very similar reasons.
+	 *
+	 * Moreover, on machines with SandyBridge graphics or in setups that use
+	 * crashkernel the entire 1M is reserved anyway.
 	 */
 	reserve_real_mode();
 

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Linus Torvalds]

On Tue, Jun 8, 2021 at 1:01 PM Borislav Petkov <bp@alien8.de> wrote:
>
> How's that (comment re-flowed):

Ack, looks good. Additionally, please refer to this thread on
lore.kernel.org in the commit message so that we can find that
confirmation about Windows behavior, and I think we're all set.

          Linus

[PATCH] x86/setup: Document that Windows reserves the first MiB

[Borislav Petkov]

It does so unconditionally too, on Intel and AMD machines, to work
around BIOS bugs, as confirmed by Microsoft folks (see Link for full
details).

Reflow the paragraph, while at it.

Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/MWHPR21MB159330952629D36EEDE706B3D7379@MWHPR21MB1593.namprd21.prod.outlook.com
---
 arch/x86/kernel/setup.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 7638ac6c3d80..85acd22f8022 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1060,17 +1060,18 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	/*
-	 * Find free memory for the real mode trampoline and place it
-	 * there.
-	 * If there is not enough free memory under 1M, on EFI-enabled
-	 * systems there will be additional attempt to reclaim the memory
-	 * for the real mode trampoline at efi_free_boot_services().
+	 * Find free memory for the real mode trampoline and place it there. If
+	 * there is not enough free memory under 1M, on EFI-enabled systems
+	 * there will be additional attempt to reclaim the memory for the real
+	 * mode trampoline at efi_free_boot_services().
 	 *
-	 * Unconditionally reserve the entire first 1M of RAM because
-	 * BIOSes are know to corrupt low memory and several
-	 * hundred kilobytes are not worth complex detection what memory gets
-	 * clobbered. Moreover, on machines with SandyBridge graphics or in
-	 * setups that use crashkernel the entire 1M is reserved anyway.
+	 * Unconditionally reserve the entire first 1M of RAM because BIOSes
+	 * are known to corrupt low memory and several hundred kilobytes are not
+	 * worth complex detection what memory gets clobbered. Windows does the
+	 * same thing for very similar reasons.
+	 *
+	 * Moreover, on machines with SandyBridge graphics or in setups that use
+	 * crashkernel the entire 1M is reserved anyway.
 	 */
 	reserve_real_mode();
 
-- 
2.29.2

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/setup: Document that Windows reserves the first MiB

[Mike Rapoport]

On Tue, Jun 08, 2021 at 10:30:46PM +0200, Borislav Petkov wrote:
> It does so unconditionally too, on Intel and AMD machines, to work
> around BIOS bugs, as confirmed by Microsoft folks (see Link for full
> details).
> 
> Reflow the paragraph, while at it.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>

Acked-by: Mike Rapoport <rppt@linux.ibm.com>

Thanks for taking care of this!

> Link: https://lkml.kernel.org/r/MWHPR21MB159330952629D36EEDE706B3D7379@MWHPR21MB1593.namprd21.prod.outlook.com
> ---
>  arch/x86/kernel/setup.c | 21 +++++++++++----------
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 7638ac6c3d80..85acd22f8022 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1060,17 +1060,18 @@ void __init setup_arch(char **cmdline_p)
>  #endif
>  
>  	/*
> -	 * Find free memory for the real mode trampoline and place it
> -	 * there.
> -	 * If there is not enough free memory under 1M, on EFI-enabled
> -	 * systems there will be additional attempt to reclaim the memory
> -	 * for the real mode trampoline at efi_free_boot_services().
> +	 * Find free memory for the real mode trampoline and place it there. If
> +	 * there is not enough free memory under 1M, on EFI-enabled systems
> +	 * there will be additional attempt to reclaim the memory for the real
> +	 * mode trampoline at efi_free_boot_services().
>  	 *
> -	 * Unconditionally reserve the entire first 1M of RAM because
> -	 * BIOSes are know to corrupt low memory and several
> -	 * hundred kilobytes are not worth complex detection what memory gets
> -	 * clobbered. Moreover, on machines with SandyBridge graphics or in
> -	 * setups that use crashkernel the entire 1M is reserved anyway.
> +	 * Unconditionally reserve the entire first 1M of RAM because BIOSes
> +	 * are known to corrupt low memory and several hundred kilobytes are not
> +	 * worth complex detection what memory gets clobbered. Windows does the
> +	 * same thing for very similar reasons.
> +	 *
> +	 * Moreover, on machines with SandyBridge graphics or in setups that use
> +	 * crashkernel the entire 1M is reserved anyway.
>  	 */
>  	reserve_real_mode();
>  
> -- 
> 2.29.2
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

-- 
Sincerely yours,
Mike.

Re: [GIT PULL] x86/urgent for v5.13-rc5

[Andy Lutomirski]

On Tue, Jun 8, 2021, at 10:53 AM, Michael Kelley wrote:
> From: James Morris <jmorris@namei.org> Sent: Monday, June 7, 2021 11:47 AM
>> 
>> On Sun, 6 Jun 2021, Sasha Levin wrote:
>> 
>> > >
>> > >Let's see if Sasha can dig out something... CCed.
>> > >
>> > >@Sasha, can you figure out who we can talk to whether Windoze reserves
>> > >the first megabyte of memory unconditionally?
>> >
>> > That's a great question, but I can't help there anymore :)
>> >
>> > Adding James Morris...
>> 
>> Adding Michael Kelley.
>> 
>
> I checked with the Windows team.  Peter Anvin's statement from 11
> years ago is true.  On Intel and AMD processors, Windows unconditionally
> reserves the 1st megabyte of memory, minus one page used for real
> mode startup.   This is done to work around BIOS bugs.

Sorry to dredge up old skeletons.  Do you know *where* Windows allocates that one page used for real mode startup?  The current code in Linux has some bugs allocating that page, and it would be nice to sort it out.

RE: [GIT PULL] x86/urgent for v5.13-rc5

[Michael Kelley (LINUX)]

From: Andy Lutomirski <luto@kernel.org> Sent: Thursday, March 2, 2023 8:14 AM
> 
> On Tue, Jun 8, 2021, at 10:53 AM, Michael Kelley wrote:
> > From: James Morris <jmorris@namei.org> Sent: Monday, June 7, 2021 11:47 AM
> >>
> >> On Sun, 6 Jun 2021, Sasha Levin wrote:
> >>
> >> > >
> >> > >Let's see if Sasha can dig out something... CCed.
> >> > >
> >> > >@Sasha, can you figure out who we can talk to whether Windoze reserves
> >> > >the first megabyte of memory unconditionally?
> >> >
> >> > That's a great question, but I can't help there anymore :)
> >> >
> >> > Adding James Morris...
> >>
> >> Adding Michael Kelley.
> >>
> >
> > I checked with the Windows team.  Peter Anvin's statement from 11
> > years ago is true.  On Intel and AMD processors, Windows unconditionally
> > reserves the 1st megabyte of memory, minus one page used for real
> > mode startup.   This is done to work around BIOS bugs.
> 
> Sorry to dredge up old skeletons.  Do you know *where* Windows allocates that one
> page used for real mode startup?  The current code in Linux has some bugs allocating
> that page, and it would be nice to sort it out.

The Windows folks tell me that the single page is typically allocated at physical address
0x1000.   They don't allocate physical page 0, so they scan upward starting at physical
page 1 and use the first page that is not reserved by firmware.  That's usually page 1.

Michael

Re: [GIT PULL] x86/urgent for v5.13-rc5

[pr-tracker-bot]

The pull request you sent on Sun, 6 Jun 2021 09:55:52 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v5.13-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/773ac53bbfcebb58ce03577d94ce471cadf3ea18

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html