lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ