From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2262QNqupsvfRy4hJ+dQNQMOHLyZsxYJ7c3e6lXVthuQLpwmnKhBANewk9i/+ttEu8UBY9MG ARC-Seal: i=1; a=rsa-sha256; t=1516993438; cv=none; d=google.com; s=arc-20160816; b=QBhQHPFnqZQOwgJE5nOx1q/HZ7+uN+beCPowFlQgyp+OpXsmi4qhdc49xOp/TNFwVD bIpsvjAdaWkxkWtUES8RHhgz0NzRgW6HntmOTJwcNsGZKfYH9DDUQyLL/9giHBf+wsp4 da2oIpGlLJQ8EZDGnAqsu3gSGs6Nj6IZ83MTD1YKDz1Bpf+73gjeBHvpIwDVyMlmJhL/ kzzk1BwZo2pOJFdPD8O/26daWqzSSD21Z6GNc+ZNGUmQs0diG7Gh64GuRjagD07bjEgh dlIvxCP8AfA5sq3p8ZeUHT+/kLlbjTT+y7TAUBuZE/QZK+xjtONg/ylwzhmAm5vlDDb1 LMwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=5f5U29U7yOTCKkq0c5bpuqt4OLSTS/U88J75amTJyBc=; b=SZyX1dkGe+JkapeKRxfir0SQgeSQ3FmzwiaExkNS/IkX84GxaSRDmOzyN5LI432TgY 1m8SpOSuf3Kt5aIXqvF8WE3vKL9MlbBs99PyGGjtxht/gdfkP7q+z9GQkej9dYPruJTS 4G5PkmwrroUuPFwR8B0gA7xnMZkYjAKphkz81a9rY9kWvn8JUQpQ6OzB7ixDnhGBqP7T 8CQTI5SZzFzG/I8jmaKl9HsL2ZuB1J9KFZ9fiif+1TroHpEnLgLoToe77Zausx15Fwn9 VeCJBR+tGWRiHuez17l//qn7MIceqKBYEviEkxPtqliS2bg7mzaA4kEnGy9YzoB2Eoc2 p9mQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=ULDBQHWf; spf=pass (google.com: domain of konrad.wilk@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=konrad.wilk@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=ULDBQHWf; spf=pass (google.com: domain of konrad.wilk@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=konrad.wilk@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Date: Fri, 26 Jan 2018 14:02:57 -0500 From: Konrad Rzeszutek Wilk To: Andi Kleen Cc: Linus Torvalds , David Woodhouse , Dave Hansen , Liran Alon , Laura Abbott , Andrew Lutomirski , Janakarajan Natarajan , Borislav Petkov , "Mallick, Asit K" , Radim =?utf-8?B?S3LEjW3DocWZ?= , KarimAllah Ahmed , Peter Anvin , Jun Nakajima , Ingo Molnar , the arch/x86 maintainers , Ashok Raj , "Van De Ven, Arjan" , Tim Chen , Paolo Bonzini , Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , Greg Kroah-Hartman , Masami Hiramatsu , Arjan van de Ven , Tom Lendacky , Dan Williams , Joerg Roedel , Andrea Arcangeli , KVM list , Boris Ostrovsky Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Message-ID: <20180126190257.GS14668@char.us.oracle.com> References: <7c0b0879-3448-43e4-8380-4708fc787113@default> <50c5d627-8975-184b-b50f-4cc02c5816c5@intel.com> <1516957886.30244.161.camel@infradead.org> <20180126175901.GL26209@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180126175901.GL26209@tassilo.jf.intel.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8786 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=766 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801260249 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590682912485966784?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Jan 26, 2018 at 09:59:01AM -0800, Andi Kleen wrote: > On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote: > > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse wrote: > > > > > > Do we need to look again at the fact that we've disabled the RSB- > > > stuffing for SMEP? > > > > Absolutely. SMEP helps make people a lot less worried about things, > > but it doesn't fix the "BTB only contains partial addresses" case. > > > > But did we do that "disable stuffing with SMEP"? I'm not seeing it. In > > my tree, it's only conditional on X86_FEATURE_RETPOLINE. > > For Skylake we need RSB stuffing even with SMEP to avoid falling back to the > BTB on underflow. > > It's also always needed with virtualization. -ECONFUSED, see ==> Is this incorrect then? I see: 241 * Skylake era CPUs have a separate issue with *underflow* of the 242 * RSB, when they will predict 'ret' targets from the generic BTB. 243 * The proper mitigation for this is IBRS. If IBRS is not supported 244 * or deactivated in favour of retpolines the RSB fill on context 245 * switch is required. 246 */ which came from this: commit c995efd5a740d9cbafbf58bde4973e8b50b4d761 Author: David Woodhouse Date: Fri Jan 12 17:49:25 2018 +0000 x86/retpoline: Fill RSB on context switch for affected CPUs On context switch from a shallow call stack to a deeper one, as the CPU does 'ret' up the deeper side it may encounter RSB entries (predictions for where the 'ret' goes to) which were populated in userspace. This is problematic if neither SMEP nor KPTI (the latter of which marks userspace pages as NX for the kernel) are active, as malicious code in userspace may then be executed speculatively. Overwrite the CPU's return prediction stack with calls which are predicted to return to an infinite loop, to "capture" speculation if this happens. This is required both for retpoline, and also in conjunction with IBRS for !SMEP && !KPTI. On Skylake+ the problem is slightly different, and an *underflow* of the RSB may cause errant branch predictions to occur. So there it's not so much overwrite, as *filling* the RSB to attempt to prevent it getting empty. This is only a partial solution for Skylake+ since there are many ==>other conditions which may result in the RSB becoming empty. The full <== ==>solution on Skylake+ is to use IBRS, which will prevent the problem even <== when the RSB becomes empty. With IBRS, the RSB-stuffing will not be required on context switch. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Acked-by: Arjan van de Ven The "full solution" is what is making me confused. > > -Andi