From: Matthias Welwarsky <matthias.welwarsky@sysgo.com>
To: Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>
Cc: linux-kernel@vger.kernel.org, x86-ml <x86@kernel.org>,
Borislav Petkov <bp@alien8.de>
Subject: Re: x86, possible bug in __memmove() alternatives patching
Date: Sat, 26 Mar 2022 12:39:23 +0100 [thread overview]
Message-ID: <3346653.QJadu78ljV@linux-3513> (raw)
In-Reply-To: <d9d0405e-b118-b028-d26f-fbb8de4e7a0e@intel.com>
On Samstag, 26. März 2022 05:45:24 CET 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. ;)
Of course, no doubt about that.
> 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.
The question is whether a sequence like this could be relevant:
0) CPU announces feature FSRM through cpuid
1) BIOS/firmware disables fast string ops through IA32_MISC_ENABLE before
loading kernel (for whatever reason)
2) Kernel populates features from cpuid
3) Kernel clears ERMS based on IA32_MISC_ENABLE
4) "alternatives" patching destroys __memmove()
That depends on whether a cpuid instruction after step 1) would still announce
FSRM. If not, then the whole point is moot and no patch needed (unless we want
to guard against hypervisor bugs).
--
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@sysgo.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
next prev parent reply other threads:[~2022-03-26 11:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 8:51 x86, possible bug in __memmove() alternatives patching Matthias Welwarsky
2022-03-25 22:07 ` Borislav Petkov
2022-03-26 4:45 ` Dave Hansen
2022-03-26 8:27 ` Borislav Petkov
2022-03-29 22:34 ` Dave Hansen
2022-03-26 11:39 ` Matthias Welwarsky [this message]
2022-03-29 22:33 ` Dave Hansen
2022-03-30 13:56 ` Matthias Welwarsky
2022-03-30 14:44 ` Dave Hansen
2022-03-30 14:54 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3346653.QJadu78ljV@linux-3513 \
--to=matthias.welwarsky@sysgo.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.