public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	Daniel Verkamp <dverkamp@chromium.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH] x86: also disable FSRM if ERMS is disabled
Date: Sat, 14 Jan 2023 10:19:40 +0100	[thread overview]
Message-ID: <Y8JzrLuJ0EJRPFGQ@gmail.com> (raw)
In-Reply-To: <Y7VlZsaWz4/b6Phf@zn.tnic>


* Borislav Petkov <bp@alien8.de> wrote:

> On Wed, Jan 04, 2023 at 08:43:51AM +0100, Jiri Slaby wrote:
> > Let me resurrect this thread... Our customer has an AMD CPU which has indeed
> > both capabilities under normal circumstances. But they have a cool UEFI BIOS
> > too. They say:
> > 
> > """
> > In AMD platform, while disalbe ERMS(Enhanced Rep MOVSB/STOSB) in UEFI
> > (system setup -> processor -> Enhanced Rep MOVSB/STOSB), the OS can't boot
> > normally.
> 
> Any particular reason they're disabling ERMS?
> 
> What do they set FSRM to?

Nevertheless both Jiri and Daniel are making a valid argument: our x86 
memcpy routines should not behave in an undefined fashion, *regardless* of 
what CPUID environment we are in.

As practice has shown, both on virtual and on bare metal firmware can screw 
things up enough so that the memcpy routines crash under Linux but under no 
other OS...

So while you are technically correct that these are firmware bugs, I'm in 
favor of robustifying our x86 memcpy routines against these bugs. Silently 
not booting, where no other OS fails to boot, is poor form IMO.

Thanks,

	Ingo

  reply	other threads:[~2023-01-14  9:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23  0:58 [PATCH] x86: also disable FSRM if ERMS is disabled Daniel Verkamp
2022-09-23 11:13 ` Borislav Petkov
2022-09-23 17:25   ` Daniel Verkamp
2022-09-23 17:51     ` Borislav Petkov
2022-10-07 18:08       ` Daniel Verkamp
2022-10-11 11:28         ` Borislav Petkov
2022-10-11 17:09           ` Luck, Tony
2022-10-11 17:52             ` Borislav Petkov
2022-10-11 19:08               ` Luck, Tony
2022-10-11 20:56                 ` Borislav Petkov
2022-10-11 22:19                   ` Luck, Tony
2022-10-11 22:59                     ` Andrew Cooper
2023-01-04  7:43         ` Jiri Slaby
2023-01-04 11:39           ` Borislav Petkov
2023-01-14  9:19             ` Ingo Molnar [this message]
2023-01-14  9:58               ` Borislav Petkov
2023-01-16  5:26             ` Jiri Slaby
2023-01-16 21:17               ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y8JzrLuJ0EJRPFGQ@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=dverkamp@chromium.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox