From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965140AbeALSFy (ORCPT + 1 other); Fri, 12 Jan 2018 13:05:54 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:30673 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964803AbeALSFx (ORCPT ); Fri, 12 Jan 2018 13:05:53 -0500 X-IronPort-AV: E=Sophos;i="5.46,350,1511827200"; d="scan'208";a="65987715" Subject: Re: [PATCH] x86/retpoline: Fill RSB on context switch for affected CPUs To: David Woodhouse , Andi Kleen CC: Paul Turner , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , , Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , , , , Josh Poimboeuf References: <1515779365-9032-1-git-send-email-dwmw@amazon.co.uk> From: Andrew Cooper Message-ID: Date: Fri, 12 Jan 2018 18:05:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1515779365-9032-1-git-send-email-dwmw@amazon.co.uk> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 12/01/18 17:49, David Woodhouse wrote: > When we context switch from a shallow call stack to a deeper one, as we > 'ret' up the deeper side we may encounter RSB entries (predictions for > where the 'ret' goes to) which were populated in userspace. This is > problematic if we have neither SMEP nor KPTI (the latter of which marks > userspace pages as NX for the kernel), as malicious code in userspace > may then be executed speculatively. So 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. If you unconditionally fill the RSB on every entry to supervisor mode, then there are never guest-controlled RSB values to be found. With that property (and IBRS to protect Skylake+), you shouldn't need RSB filling anywhere in the middle. ~Andrew