[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8JzrLuJ0EJRPFGQ@gmail.com>
Date: Sat, 14 Jan 2023 10:19:40 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Jiri Slaby <jirislaby@...nel.org>,
Daniel Verkamp <dverkamp@...omium.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH] x86: also disable FSRM if ERMS is disabled
* Borislav Petkov <bp@...en8.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
Powered by blists - more mailing lists