Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp755757ybl; Wed, 29 Jan 2020 09:09:04 -0800 (PST) X-Google-Smtp-Source: APXvYqzJ2hcBnh8rrYbMEsdTb+GH2f2EycT6Sjf9dXQrXBVKHceou44Uwz472f35LHhvinpRutc8 X-Received: by 2002:a9d:560f:: with SMTP id e15mr163554oti.301.1580317744846; Wed, 29 Jan 2020 09:09:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580317744; cv=none; d=google.com; s=arc-20160816; b=KvaiG3vlejfnKiEQ15YncZFEwqEjCjBU4n7XdqNc1Rt7qpyKckNZKtrnap4YCOlzGX c4qe7aEm76u2URaHz1eiGEuh6c9v70mwxflL7GlHRqh1hK6xo1707LMfXuPywqet2KoY VTb0byKqHMOm3ZraVF70Lulzb9Ep6XFZ1wy1J9F1GF5zzizBlqyaeHhDZrJmEP0z+YJ3 fZe9wNp6yuefTVImmglDihCce/utaTDFvYUjXYnvyAZxC3MPDm0JeYML5ApaMgHDz/v7 SUUVrnYpOfBnqnoIafin+sefWkZ5IyauKxhsWVOuRGi8oVuSBkhWL3mNWrJNGAOqasx0 QJ4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ngrNL7N7qcbfBBh0llL+jg/vapsFJu53ZaxDYJzgQEk=; b=T1qBYV4yPcJJdecOnZ1NuMIA6pBGKeQVKSzkTQ+9OEFRnIpxv6HfuhZ7nwhZy7hyaD cr7cy+GxdVWQYOmAp7wm8fbQozo+MzppahRaIV+tN5lww+F01Ycj+f34Yof9n0IbYmzE 7fZr8aaxKAEXhoqYnDTReObQXdSse1uNlOj/eNpGwGCOIPy+FRWeIN3vNwsFT7xgrVof BDmAQV+SnHnvB0Phbg3HV9B6AywXbn4rBpqQKQ0utqbzYRg9Oa6wFAKDZRT4zCzYrOjy 5YHQtJdILewfuBXtnarv8nUuNZ/j8yDPiJ1LgWamM0poCYjXOEK/Y7NduGV1+zS6igog 0iug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y186si1339230oig.241.2020.01.29.09.08.52; Wed, 29 Jan 2020 09:09:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727235AbgA2RH1 (ORCPT + 99 others); Wed, 29 Jan 2020 12:07:27 -0500 Received: from mga17.intel.com ([192.55.52.151]:36373 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726927AbgA2RH0 (ORCPT ); Wed, 29 Jan 2020 12:07:26 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2020 09:07:26 -0800 X-IronPort-AV: E=Sophos;i="5.70,378,1574150400"; d="scan'208";a="223890527" Received: from agluck-desk2.sc.intel.com (HELO agluck-desk2.amr.corp.intel.com) ([10.3.52.68]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2020 09:07:26 -0800 Date: Wed, 29 Jan 2020 09:07:25 -0800 From: "Luck, Tony" To: Borislav Petkov Cc: Linus Torvalds , Ingo Molnar , Linux Kernel Mailing List , Thomas Gleixner , Borislav Petkov , Peter Zijlstra , Andrew Morton Subject: Re: [GIT PULL] x86/asm changes for v5.6 Message-ID: <20200129170725.GA21265@agluck-desk2.amr.corp.intel.com> References: <20200128165906.GA67781@gmail.com> <20200129132618.GA30979@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200129132618.GA30979@zn.tnic> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 29, 2020 at 02:26:18PM +0100, Borislav Petkov wrote: > On Tue, Jan 28, 2020 at 12:06:53PM -0800, Linus Torvalds wrote: > > On Tue, Jan 28, 2020 at 11:51 AM Linus Torvalds > > wrote: > > > > > > ALTERNATIVE_2 \ > > > "cmp $680, %rdx ; jb 3f ; cmpb %dil, %sil; je 4f", \ > > > "movq %rdx, %rcx ; rep movsb; retq", X86_FEATURE_FSRM, \ > > > "cmp $0x20, %rdx; jb 1f; movq %rdx, %rcx; rep movsb; retq", X86_FEATURE_ERMS > > > > Note the UNTESTED part. > > > > In particular, I didn't check what the priority for the alternatives > > is. Since FSRM being set always implies ERMS being set too, it may be > > that the ERMS case is always picked with the above code. So I wrote a tiny function to test (rather than wrestle with trying to disassemble the post-alternative patched binary of the running system): .globl feature .type feature, @function feature: .cfi_startproc ALTERNATIVE_2 \ "movl $1, %eax", \ "movl $2, %eax", X86_FEATURE_FSRM, \ "movl $3, %eax", X86_FEATURE_ERMS ret This returns "3" ... not what we want. But swapping the ERMS/FSRM order gets the correct version. > And yes, your idea makes sense to use ALTERNATIVE_2 but as it is, it > triple-faults my guest. I'll debug it more later to find out why, when I > get a chance. Triple fault is a surprise. As long as you have ERMS, it shouldn't hurt to take the FSRM code path. Does the code that performs the patch use memmove() to copy the alternate version into place? That could get ugly! I'm not in the same city as my test machine, so I'm going to defer testing Linus' patch (with FSRM/ERMS swapped) until I'm near enough to poke it if it breaks. -Tony