linux-kernel - x86, possible bug in __memmove() alternatives patching

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <3422754.iIbC2pHGDl@linux-3513>
Date:   Fri, 25 Mar 2022 09:51:09 +0100
From:   Matthias Welwarsky <matthias.welwarsky@...go.com>
To:     linux-kernel@...r.kernel.org
Subject: x86, possible bug in __memmove() alternatives patching

Hi list,

I've come across an odd behavior that I'm not sure whether it counts as a bug.
I'm working on an x86 hypervisor at the moment and there was an odd problem 
with a linux guest system dying during booting, but only on an intel NUC11 
(i3-1115G4). It booted normally on any other system I tested on.

The guest was usin kernel version 5.10.89.

Now, the reason eventually turned out to be __memmove() getting broken when 
applying the alternatives. The CPU on the NUC11 has the FSRM feature, which 
enables a particular alternative in __memmove(). However, the code assumes 
that the ERMS feature is always present with FSRM, otherwise the function gets 
broken. Of course this is normally the case, a CPU without ERMS would never 
advertise FSRM.

However: in the function early_intel_setup(), the ERMS feature might get 
cleared depending on the IA32_MISC_ENABLE MSR: if fast string operations are 
disabled through this MSR, X86_FEATURE_ERMS is removed from the available set, 
but X86_FEATURE_FSRM is not removed.

Now, the hypervisor I'm working on emulates this MSR and in the particular 
case, fast string ops were reported as disabled, leading to the above 
mentioned inconsistency in __memmove().

The Intel SDM doesn't go into any details if disabling fast string ops through 
IA32_MISC_ENABLE will also clear FSRM from cpuid leaf 7, but I think that's 
not relevant for the linux kernel anyway because cpuid is parsed before MSRs 
are evaluated.

I know it's is probably a very rare case and Intel recommends having fast 
string ops enabled, hence the question: would this be considered a bug in the 
kernel that should be fixed? A potential fix could be to clear FSRM together 
with ERMS depending on IA32_MISC_ENABLE.

Mit freundlichen Grüßen/Best regards,

Matthias Welwarsky
Project Engineer

SYSGO GmbH
Office Mainz
Am Pfaffenstein 8 / D-55270 Klein-Winternheim / Germany
Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
E-mail: matthias.welwarsky@...go.com
_________________________________________________________________________________
Web: https://www.sysgo.com
Blog: https://www.sysgo.com/blog
Events: https://www.sysgo.com/events
Newsletter: https://www.sysgo.com/newsletter
_________________________________________________________________________________
Handelsregister/Commercial Registry: HRB Mainz 90 HRB 48884 
Geschäftsführung/Managing Directors: Etienne Butery (CEO), Kai Sablotny (COO) 
USt-Id-Nr./VAT-Id-No.: DE 149062328 

The protection of your personal data is important to us. Under the following 
link 
you can see the information in accordance with article 13 GDPR: 
https://www.sysgo.com/privacy_policy