Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932415AbeAHMto (ORCPT + 1 other); Mon, 8 Jan 2018 07:49:44 -0500 Received: from twosheds.infradead.org ([90.155.92.209]:32850 "EHLO twosheds.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756379AbeAHMtm (ORCPT ); Mon, 8 Jan 2018 07:49:42 -0500 Message-ID: In-Reply-To: References: <1515363085-4219-1-git-send-email-dwmw@amazon.co.uk> <1515408317.7317.31.camel@infradead.org> Date: Mon, 8 Jan 2018 12:49:39 -0000 Subject: Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel From: "David Woodhouse" To: "Paul Turner" Cc: "David Woodhouse" , "Andi Kleen" , "LKML" , "Linus Torvalds" , "Greg Kroah-Hartman" , "Tim Chen" , "Dave Hansen" , "Thomas Gleixner" , "Kees Cook" , "Rik van Riel" , "Peter Zijlstra" , "Andy Lutomirski" , "Jiri Kosina" , "One Thousand Gnomes" User-Agent: SquirrelMail/1.4.22-21.fc27 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SRS-Rewrite: SMTP reverse-path rewritten from by twosheds.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > On Mon, Jan 8, 2018 at 2:45 AM, David Woodhouse > wrote: >> On Mon, 2018-01-08 at 02:34 -0800, Paul Turner wrote: >>> One detail that is missing is that we still need RSB refill in some >>> cases. >>> This is not because the retpoline sequence itself will underflow (it >>> is actually guaranteed not to, since it consumes only RSB entries >>> that it generates. >>> But either to avoid poisoning of the RSB entries themselves, or to >>> avoid the hardware turning to alternate predictors on RSB underflow. >>> >>> Enumerating the cases we care about: >>> >>> • user->kernel in the absence of SMEP: >>> In the absence of SMEP, we must worry about user-generated RSB >>> entries being consumable by kernel execution. >>> Generally speaking, for synchronous execution this will not occur >>> (e.g. syscall, interrupt), however, one important case remains. >>> When we context switch between two threads, we should flush the RSB >>> so that execution generated from the unbalanced return path on the >>> thread that we just scheduled into, cannot consume RSB entries >>> potentially installed by the prior thread. >> >> Or IBPB here, yes? That's what we had in the original patch set when >> retpoline came last, and what I assume will be put back again once we >> *finally* get our act together and reinstate the full set of microcode >> patches. > > IBPB is *much* more expensive than the sequence I suggested. > If the kernel has been protected with a retpoline compilation, it is > much faster to not use IBPB here; we only need to prevent > ret-poisoning in this case. Retpoline protects the kernel but IBPB is needed on context switch anyway to protect userspace processes from each other. But... > A) I am enumerating all of the cases for completeness. It was missed > by many that this detail was necessary on this patch, independently of > IBRS. > B) On the parts duplicated in (A), for specifics that are contributory to > correctness in both cases, we should not hand-wave over the fact that > they may or may not be covered by another patch-set. Users need to > understand what's required for complete protection. Particularly if they > are backporting. ... yes, agreed. Now we are putting retpoline first we shouldn't miss things that we *were* doing anyway. TBH I really don't think we should have spilt the patch sets apart; we'll work on getting the rest on top ASAP. -- dwmw2