All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] x86/urgent for v5.13-rc5
@ 2021-06-06  7:55 Borislav Petkov
  2021-06-06 19:38 ` Linus Torvalds
  2021-06-06 20:14 ` pr-tracker-bot
  0 siblings, 2 replies; 17+ messages in thread
From: Borislav Petkov @ 2021-06-06  7:55 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: x86-ml, lkml

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06  7:55 [GIT PULL] x86/urgent for v5.13-rc5 Borislav Petkov
@ 2021-06-06 19:38 ` Linus Torvalds
  2021-06-06 20:58   ` Mike Rapoport
  2021-06-06 20:14 ` pr-tracker-bot
  1 sibling, 1 reply; 17+ messages in thread
From: Linus Torvalds @ 2021-06-06 19:38 UTC (permalink / raw)
  To: Borislav Petkov, Mike Rapoport; +Cc: x86-ml, lkml

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06  7:55 [GIT PULL] x86/urgent for v5.13-rc5 Borislav Petkov
  2021-06-06 19:38 ` Linus Torvalds
@ 2021-06-06 20:14 ` pr-tracker-bot
  1 sibling, 0 replies; 17+ messages in thread
From: pr-tracker-bot @ 2021-06-06 20:14 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06 19:38 ` Linus Torvalds
@ 2021-06-06 20:58   ` Mike Rapoport
  2021-06-06 21:23     ` Linus Torvalds
  0 siblings, 1 reply; 17+ messages in thread
From: Mike Rapoport @ 2021-06-06 20:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Borislav Petkov, x86-ml, lkml

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.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06 20:58   ` Mike Rapoport
@ 2021-06-06 21:23     ` Linus Torvalds
  2021-06-06 22:07       ` Borislav Petkov
  0 siblings, 1 reply; 17+ messages in thread
From: Linus Torvalds @ 2021-06-06 21:23 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: Borislav Petkov, x86-ml, lkml

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06 21:23     ` Linus Torvalds
@ 2021-06-06 22:07       ` Borislav Petkov
  2021-06-06 23:05         ` Sasha Levin
  0 siblings, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2021-06-06 22:07 UTC (permalink / raw)
  To: Linus Torvalds, Sasha Levin; +Cc: Mike Rapoport, x86-ml, lkml

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06 22:07       ` Borislav Petkov
@ 2021-06-06 23:05         ` Sasha Levin
  2021-06-07 18:46           ` James Morris
  0 siblings, 1 reply; 17+ messages in thread
From: Sasha Levin @ 2021-06-06 23:05 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Linus Torvalds, Mike Rapoport, x86-ml, lkml, James.Morris

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-06 23:05         ` Sasha Levin
@ 2021-06-07 18:46           ` James Morris
  2021-06-08 17:53             ` Michael Kelley
  0 siblings, 1 reply; 17+ messages in thread
From: James Morris @ 2021-06-07 18:46 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Borislav Petkov, Linus Torvalds, Mike Rapoport, x86-ml, lkml,
	James.Morris, mikelley

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>


^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-07 18:46           ` James Morris
@ 2021-06-08 17:53             ` Michael Kelley
  2021-06-08 18:33               ` Borislav Petkov
  2023-03-02 16:14               ` [GIT PULL] x86/urgent for v5.13-rc5 Andy Lutomirski
  0 siblings, 2 replies; 17+ messages in thread
From: Michael Kelley @ 2021-06-08 17:53 UTC (permalink / raw)
  To: James Morris, Sasha Levin, Linus Torvalds, Mike Rapoport,
	Borislav Petkov
  Cc: x86-ml, lkml, James Morris

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-08 17:53             ` Michael Kelley
@ 2021-06-08 18:33               ` Borislav Petkov
  2021-06-08 19:22                 ` Linus Torvalds
  2023-03-02 16:14               ` [GIT PULL] x86/urgent for v5.13-rc5 Andy Lutomirski
  1 sibling, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2021-06-08 18:33 UTC (permalink / raw)
  To: Michael Kelley, Linus Torvalds
  Cc: James Morris, Sasha Levin, Mike Rapoport, x86-ml, lkml, James Morris

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-08 18:33               ` Borislav Petkov
@ 2021-06-08 19:22                 ` Linus Torvalds
  2021-06-08 20:01                   ` Borislav Petkov
  0 siblings, 1 reply; 17+ messages in thread
From: Linus Torvalds @ 2021-06-08 19:22 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Michael Kelley, James Morris, Sasha Levin, Mike Rapoport, x86-ml,
	lkml, James Morris

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-08 19:22                 ` Linus Torvalds
@ 2021-06-08 20:01                   ` Borislav Petkov
  2021-06-08 20:03                     ` Linus Torvalds
  0 siblings, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2021-06-08 20:01 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Michael Kelley, James Morris, Sasha Levin, Mike Rapoport, x86-ml,
	lkml, James Morris

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

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-08 20:01                   ` Borislav Petkov
@ 2021-06-08 20:03                     ` Linus Torvalds
  2021-06-08 20:30                       ` [PATCH] x86/setup: Document that Windows reserves the first MiB Borislav Petkov
  0 siblings, 1 reply; 17+ messages in thread
From: Linus Torvalds @ 2021-06-08 20:03 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Michael Kelley, James Morris, Sasha Levin, Mike Rapoport, x86-ml,
	lkml, James Morris

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH] x86/setup: Document that Windows reserves the first MiB
  2021-06-08 20:03                     ` Linus Torvalds
@ 2021-06-08 20:30                       ` Borislav Petkov
  2021-06-09  8:54                         ` Mike Rapoport
  0 siblings, 1 reply; 17+ messages in thread
From: Borislav Petkov @ 2021-06-08 20:30 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Michael Kelley, James Morris, Sasha Levin, Mike Rapoport, x86-ml,
	lkml, James Morris

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

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] x86/setup: Document that Windows reserves the first MiB
  2021-06-08 20:30                       ` [PATCH] x86/setup: Document that Windows reserves the first MiB Borislav Petkov
@ 2021-06-09  8:54                         ` Mike Rapoport
  0 siblings, 0 replies; 17+ messages in thread
From: Mike Rapoport @ 2021-06-09  8:54 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Linus Torvalds, Michael Kelley, James Morris, Sasha Levin,
	x86-ml, lkml, James Morris

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.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [GIT PULL] x86/urgent for v5.13-rc5
  2021-06-08 17:53             ` Michael Kelley
  2021-06-08 18:33               ` Borislav Petkov
@ 2023-03-02 16:14               ` Andy Lutomirski
  2023-03-02 21:17                 ` Michael Kelley (LINUX)
  1 sibling, 1 reply; 17+ messages in thread
From: Andy Lutomirski @ 2023-03-02 16:14 UTC (permalink / raw)
  To: Michael Kelley, James Morris, Sasha Levin, Linus Torvalds,
	Mike Rapoport, Borislav Petkov
  Cc: the arch/x86 maintainers, Linux Kernel Mailing List, James Morris

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.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: [GIT PULL] x86/urgent for v5.13-rc5
  2023-03-02 16:14               ` [GIT PULL] x86/urgent for v5.13-rc5 Andy Lutomirski
@ 2023-03-02 21:17                 ` Michael Kelley (LINUX)
  0 siblings, 0 replies; 17+ messages in thread
From: Michael Kelley (LINUX) @ 2023-03-02 21:17 UTC (permalink / raw)
  To: Andy Lutomirski, James Morris, Sasha Levin, Linus Torvalds,
	Mike Rapoport, Borislav Petkov
  Cc: the arch/x86 maintainers, Linux Kernel Mailing List, James Morris

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2023-03-02 21:56 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-06  7:55 [GIT PULL] x86/urgent for v5.13-rc5 Borislav Petkov
2021-06-06 19:38 ` Linus Torvalds
2021-06-06 20:58   ` Mike Rapoport
2021-06-06 21:23     ` Linus Torvalds
2021-06-06 22:07       ` Borislav Petkov
2021-06-06 23:05         ` Sasha Levin
2021-06-07 18:46           ` James Morris
2021-06-08 17:53             ` Michael Kelley
2021-06-08 18:33               ` Borislav Petkov
2021-06-08 19:22                 ` Linus Torvalds
2021-06-08 20:01                   ` Borislav Petkov
2021-06-08 20:03                     ` Linus Torvalds
2021-06-08 20:30                       ` [PATCH] x86/setup: Document that Windows reserves the first MiB Borislav Petkov
2021-06-09  8:54                         ` Mike Rapoport
2023-03-02 16:14               ` [GIT PULL] x86/urgent for v5.13-rc5 Andy Lutomirski
2023-03-02 21:17                 ` Michael Kelley (LINUX)
2021-06-06 20:14 ` pr-tracker-bot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.