From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A882C433EF for ; Sat, 26 Mar 2022 11:39:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232685AbiCZLlG convert rfc822-to-8bit (ORCPT ); Sat, 26 Mar 2022 07:41:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbiCZLlE (ORCPT ); Sat, 26 Mar 2022 07:41:04 -0400 X-Greylist: delayed 96494 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sat, 26 Mar 2022 04:39:27 PDT Received: from mail.sysgo.com (mail.sysgo.com [159.69.174.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7E174E3B5 for ; Sat, 26 Mar 2022 04:39:26 -0700 (PDT) From: Matthias Welwarsky To: Borislav Petkov , Dave Hansen , Dave Hansen Cc: linux-kernel@vger.kernel.org, x86-ml , Borislav Petkov Subject: Re: x86, possible bug in __memmove() alternatives patching Date: Sat, 26 Mar 2022 12:39:23 +0100 Message-ID: <3346653.QJadu78ljV@linux-3513> Organization: SYSGO GmbH In-Reply-To: References: <3422754.iIbC2pHGDl@linux-3513> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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