linux-kernel - RE: [PATCH] x86: also disable FSRM if ERMS is disabled

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]

Date:   Tue, 11 Oct 2022 19:08:51 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Daniel Verkamp <dverkamp@...omium.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>
Subject: RE: [PATCH] x86: also disable FSRM if ERMS is disabled

> If something clears MSR_IA32_MISC_ENABLE_FAST_STRING_BIT and we go and
> clear our feature flags and luserspace still queries CPUID then oh well,
> it'll be fun. It all depends on why something has cleared them tho. It
> could be some performance thing or something a lot more funky. I guess
> if stuff starts exploding left and right, there will soon be a microcode
> patch after that. :-)

Yes. ERMS CPUID bit was the early indicator to s/w that REP MOVS would
do some fancy speedups if certain conditions about source, destination and
count are all met. A hint to s/w to decide which memcpy() routine to use.

FSRM is a hint that the byte count restriction had pretty much been removed
so s/w can use REP MOVS in even more places.

I don't think Intel will deliberately release a CPU that has FSRM=1, ERMS=0.

-Tony