Received: by 10.213.65.68 with SMTP id h4csp1283889imn; Wed, 21 Mar 2018 07:09:05 -0700 (PDT) X-Google-Smtp-Source: AG47ELt/muIzXbfV5r9N+t3rBw5ccKIG0D8S95qW+Dqe//BGj7yAcRgTygoztl3Cu7Sg+1vo1ycz X-Received: by 10.98.160.92 with SMTP id r89mr14626786pfe.235.1521641345918; Wed, 21 Mar 2018 07:09:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521641345; cv=none; d=google.com; s=arc-20160816; b=sY1W2XrRtzsZib2yeSBVOcBUK6laMw2cZRSSUjjgZi/0wj2SshsZwdNegQ1f3xFVCv hy7rxQga+dbhebPAql3664rrnuZ2q7dUMD87xGHFpQQa3DqUcTMyr2GCwdjqblaVav4M ulS6OZQgYp+GUSmo76LMgtzHYFWc52MVuFqS1+KSIG6pU/U0+Fjf84v6SDlkK0oVXP+7 Ia+q805eCgLOvPexAaExczV7ScuTQOXVzeLKJumPLeyGoRB3CQzkMZaF+VwjSxDzkqbY jRTd12OCMdsZBwQFRNIYgL+Q2WsWKwXrYar++qtOVN111vqlL6OiRnP5iXIBmHAUmPWb cWEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=bVjlI+qgBvER66Hx+IsYT3dgAE4xEXsC3Rq0xO53wXU=; b=CIJ1n0BmVByvB/IvACr+uA3XsuVfuvVJLTPtNnusKpkmamqRrPL3zvV7a3kVNr6Cw9 EO7puHN0OviokPP+O6sU7PYieD0fMRtnKqiIwiwK3TOD9dJMmiM5lXu2DmBOFyeXS4vQ 5t9UDVNjvnp9ETxbqPNvc09F3LP/PORYQzjaZ+EVC5ZIAtmkWJvHj/fzSC4g6OGqWEyQ AhrUpCZ6RS5uttYV3cC5QvlqlqnIjyeDYpxWfDU4uVtknOJrbgLbNeMRDDcxattmCcEP vobV0xYzsgXWzLQh2QLaJHA8HfY1xyVil3bt4DItUYMSDHqYRma6ViSrc5PEzTQH3OBE Vlzg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 206si2902010pfa.409.2018.03.21.07.08.52; Wed, 21 Mar 2018 07:09:05 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbeCUOF0 (ORCPT + 99 others); Wed, 21 Mar 2018 10:05:26 -0400 Received: from mga06.intel.com ([134.134.136.31]:55459 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751856AbeCUOFU (ORCPT ); Wed, 21 Mar 2018 10:05:20 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 07:05:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,340,1517904000"; d="scan'208";a="213566803" Received: from kinllee-mobl.amr.corp.intel.com (HELO [10.252.135.150]) ([10.252.135.150]) by fmsmga005.fm.intel.com with ESMTP; 21 Mar 2018 07:05:18 -0700 Subject: Re: [PATCH] x86/speculation: Fill the RSB on context switch also on non-IBPB CPUs To: "Maciej S. Szmigiero" , Thomas Gleixner , Ingo Molnar References: <9eb945bd-f77e-0301-d977-d1acf931b19d@maciej.szmigiero.name> Cc: "H. Peter Anvin" , David Woodhouse , KarimAllah Ahmed , Andi Kleen , Tim Chen , thomas.lendacky@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org From: Dave Hansen Message-ID: Date: Wed, 21 Mar 2018 07:05:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9eb945bd-f77e-0301-d977-d1acf931b19d@maciej.szmigiero.name> Content-Type: text/plain; charset=iso-8859-2 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/20/2018 04:17 AM, Maciej S. Szmigiero wrote: > If we run on a CPU that does not have IBPB support RSB entries from one > userspace process can influence 'ret' target prediction in another > userspace process after a context switch. > > Since it is unlikely that existing RSB entries from the previous task match > the new task call stack we can use the existing unconditional > RSB-filling-on-context-switch infrastructure to protect against such > userspace-to-userspace attacks. > > This patch brings a change in behavior only for the following CPU types: > * Intel pre-Skylake CPUs without updated microcode, The assumption thus far (good or bad) is that everything will get a microcode update. I actually don't know for sure if RSB manipulation is effective on old microcode before Skylake. I'm pretty sure it has not been documented publicly. How did you decide that this is an effective mitigation?