Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp329888rwb; Thu, 6 Oct 2022 19:34:55 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6lz90QSzHHIBAuJmT9ToEaMdVuP0TXj5wUz1LeZ+muOKcGdjaRRgNeWCBK8szmmuudOAVX X-Received: by 2002:a05:6402:350b:b0:459:72ef:cf6b with SMTP id b11-20020a056402350b00b0045972efcf6bmr2549454edd.19.1665110094990; Thu, 06 Oct 2022 19:34:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665110094; cv=none; d=google.com; s=arc-20160816; b=hR2b2W+BLgGsA8FdxxBUzZEZ5h8TTOjvjIWB2v4NBpAjGQJFWjWA7orlWw+6vTiWeR OOp7cY3ZUNtIZKzcVF9zSg1G9yZlyTk/Cd4lqiGj/dU6wkFVM/9+HN03wRbkS3t2cJfP wdpBn1vPuLx0hK3XsgEaOCAAzNlSYyVukNj5TaysWxdWs0HGU+5lT8OcUQsBGthuQ4Rd ZwAVUWkqM/lT3eYyQh22XRjjAAYNVGyD7dw/tH45UfbWOzGnCfd9QxBinzl+8/OhXMGz KmwZ4422SjsatbT8dgaF+ftWra4Wkr0TDNK6eHB9DpPm5MxmWB2Lp75YMVLot/jf/yIe DBnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9OVOm9eDtKJN7qyZMh1z05mjjfPmqKiVIGSFHi9feuU=; b=hy54wCBuCTInFrVTZHQPa1Coye5tr5os01Mp4PCcRcsKj2GeHnVsqfW03dgsFZLykG BwpB/6MKl/4ZH1p+tdcsMwtFFGUOXGXLL9HuosOX/h54s2V/KdgOz6o/+0fIKHJOzAFR hwxiLq0eC96dlsEa+/bzQp9zskNfpV2pneu3Q4+0348g9h2rYp9xOqE4zYgmiu6D0mt0 L2esGzPoNGrsA6szZUY+VR4KjP0avWK8J+/bP9V/HRrk4Edh0bINb9MjELNAXVeAZYYS ffTpK7Q0Pl2Hq1S3wN0IpYHm5yJX1pce/kSLjjXpKednqcHa9+EJRqFSFAQZvIdJkpvX 52zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=SoZMLfNm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o10-20020a056402038a00b0045921e99f8csi730501edv.182.2022.10.06.19.34.29; Thu, 06 Oct 2022 19:34:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=SoZMLfNm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231959AbiJGByg (ORCPT + 99 others); Thu, 6 Oct 2022 21:54:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbiJGBye (ORCPT ); Thu, 6 Oct 2022 21:54:34 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A568AA3CC; Thu, 6 Oct 2022 18:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665107673; x=1696643673; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9OVOm9eDtKJN7qyZMh1z05mjjfPmqKiVIGSFHi9feuU=; b=SoZMLfNma5N2zXgMTCnGX+roMi247f4X8fMUTAPU7HdIm0q98gVTvu+5 lgIoYQet8xYiUdpzLibyhtu3BPyjEz0SUvu5QL/qVPmOBway66LrH7kJ5 vk0olUvF4zBU+XOFgcQjcKzbHU0rScZ6U5yrWAcY7GQZJi3trOoXNUxnW JoMUgOdqncczTsyDL3gCnVDd6xM0D6yGvhp5DVjNyizeoPhEiKUewb5g3 WwLjnfmUEJjrwX0hqvJlCu3prAhdZ9i0Ms6t1Umvt9YyARmeg8sPC/B2u J3ODCKVEcqajmu/Yo+KY1kThtmtR7J0+LlLb1wC47Ev4vjUGC/xLBt6Dm w==; X-IronPort-AV: E=McAfee;i="6500,9779,10492"; a="305206852" X-IronPort-AV: E=Sophos;i="5.95,164,1661842800"; d="scan'208";a="305206852" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2022 18:54:32 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10492"; a="800118233" X-IronPort-AV: E=Sophos;i="5.95,164,1661842800"; d="scan'208";a="800118233" Received: from spvenkat-mobl.amr.corp.intel.com (HELO desk) ([10.209.50.56]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2022 18:54:32 -0700 Date: Thu, 6 Oct 2022 18:54:31 -0700 From: Pawan Gupta To: Suraj Jitindar Singh Cc: kvm@vger.kernel.org, sjitindarsingh@gmail.com, linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@suse.de, dave.hansen@linux.intel.com, seanjc@google.com, pbonzini@redhat.com, peterz@infradead.org, jpoimboe@kernel.org, daniel.sneddon@linux.intel.com, benh@kernel.crashing.org, stable@vger.kernel.org Subject: Re: [PATCH] x86/speculation: Mitigate eIBRS PBRSB predictions with WRMSR Message-ID: <20221007015431.i4k4d3cxnhirnpgc@desk> References: <20221005220227.1959-1-surajjs@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221005220227.1959-1-surajjs@amazon.com> X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suraj, On Wed, Oct 05, 2022 at 03:02:27PM -0700, Suraj Jitindar Singh wrote: >tl;dr: The existing mitigation for eIBRS PBRSB predictions uses an INT3 to >ensure a call instruction retires before a following unbalanced RET. Replace >this with a WRMSR serialising instruction which has a lower performance >penalty. > >== Background == > >eIBRS (enhanced indirect branch restricted speculation) is used to prevent >predictor addresses from one privilege domain from being used for prediction >in a higher privilege domain. > >== Problem == > >On processors with eIBRS protections there can be a case where upon VM exit >a guest address may be used as an RSB prediction for an unbalanced RET if a >CALL instruction hasn't yet been retired. This is termed PBRSB (Post-Barrier >Return Stack Buffer). > >A mitigation for this was introduced in: >(2b1299322016731d56807aa49254a5ea3080b6b3 x86/speculation: Add RSB VM Exit protections) > >This mitigation [1] has a ~1% performance impact on VM exit compared to without >it [2]. > >== Solution == > >The WRMSR instruction can be used as a speculation barrier and a serialising >instruction. Use this on the VM exit path instead to ensure that a CALL >instruction (in this case the call to vmx_spec_ctrl_restore_host) has retired >before the prediction of a following unbalanced RET. > >This mitigation [3] has a negligible performance impact. > >== Testing == > >Run the outl_to_kernel kvm-unit-tests test 200 times per configuration which >counts the cycles for an exit to kernel mode. > >[1] With existing mitigation: >Average: 2026 cycles >[2] With no mitigation: >Average: 2008 cycles During these tests was the value of MSR SPEC_CTRL for host and guest different? >[3] With proposed mitigation: >Average: 2008 cycles