Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933070AbeAIBy0 (ORCPT + 1 other); Mon, 8 Jan 2018 20:54:26 -0500 Received: from mail-ua0-f194.google.com ([209.85.217.194]:41680 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932785AbeAIByZ (ORCPT ); Mon, 8 Jan 2018 20:54:25 -0500 X-Google-Smtp-Source: ACJfBotpQIbBm9szg2lzU7ZbDPEjeQHOMKO2m6KMFUukygijLKtsD5umB3PyWN22kP9mqBCWgaTaStpLW5fKZHsGMZo= MIME-Version: 1.0 In-Reply-To: <20180109012122.GA18313@tassilo.jf.intel.com> References: <1515363085-4219-1-git-send-email-dwmw@amazon.co.uk> <1515455051.15588.7.camel@infradead.org> <1515455902.4423.59.camel@amazon.co.uk> <20180109004415.GG6718@tassilo.jf.intel.com> <20180109011602.GH6718@tassilo.jf.intel.com> <20180109012122.GA18313@tassilo.jf.intel.com> From: Paul Turner Date: Mon, 8 Jan 2018 17:53:53 -0800 Message-ID: Subject: Re: [PATCH v6 11/10] x86/retpoline: Avoid return buffer underflows on context switch II To: Andi Kleen Cc: Linus Torvalds , "Woodhouse, David" , "linux-kernel@vger.kernel.org" , "tim.c.chen@linux.intel.com" , "peterz@infradead.org" , "tglx@linutronix.de" , "riel@redhat.com" , "keescook@google.com" , "gnomes@lxorguk.ukuu.org.uk" , "dave.hansen@intel.com" , "luto@amacapital.net" , "jikos@kernel.org" , "gregkh@linux-foundation.org" Content-Type: text/plain; charset="UTF-8" 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 5:21 PM, Andi Kleen wrote: > On Mon, Jan 08, 2018 at 05:16:02PM -0800, Andi Kleen wrote: >> > If we clear the registers, what the hell are you going to put in the >> > RSB that helps you? >> >> RSB allows you to control chains of gadgets. > > I admit the gadget thing is a bit obscure. > > There's another case we were actually more worried about: > > On Skylake and Broadwell when the RSB underflows it will fall back to the (Broadwell without Microcode) > indirect branch predictor, which can be poisoned and we try to avoid > using with retpoline. So we try to avoid underflows, and this filling > helps us with that. > > Does that make more sense? The majority of the confusion does not stem from this being complicated. It's that there's been great reluctance to document the details which are different -- or changed by the microcode -- even at a high level such as this. Because of this, some of the details instead include vague "things are different on Skylake" notes, with no exposition. > > -Andi