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
next prev parent 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