lkml.org 
[lkml]   [2022]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86, possible bug in __memmove() alternatives patching
On Fri, Mar 25, 2022 at 09:45:24PM -0700, Dave Hansen wrote:
> On 3/25/22 15:07, Borislav Petkov wrote:
> > 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.
>
> I'd consider it a bug in the hypervisor, personally. ;)

That's a given.

>
> But, we do try to make the kernel work even the face of funky
> hypervisors that do things that never occur on real hardware. If a nice
> patch to fix this up showed up, I'd definitely take a look.

So, more to the point, it is about this chunk:

/*
* If fast string is not enabled in IA32_MISC_ENABLE for any reason,
* clear the fast string and enhanced fast string CPU capabilities.
*/
if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING)) {
pr_info("Disabled fast string operations\n");
setup_clear_cpu_cap(X86_FEATURE_REP_GOOD);
setup_clear_cpu_cap(X86_FEATURE_ERMS);
}
}

we already check whether fast strings was disabled, regardless of HV or
not. Question is, should we clear X86_FEATURE_FSRM there too. I wanna
say yes.

Or is it that, *if* MSR_IA32_MISC_ENABLE_FAST_STRING is clear, the FSRM
CPUID bit was not set either so nothing to clear...

Hmm?

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

\
 
 \ /
  Last update: 2022-03-26 09:28    [W:0.095 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site