Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752884AbeAEVLK (ORCPT + 1 other); Fri, 5 Jan 2018 16:11:10 -0500 Received: from mail-it0-f48.google.com ([209.85.214.48]:37732 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751879AbeAEVLI (ORCPT ); Fri, 5 Jan 2018 16:11:08 -0500 X-Google-Smtp-Source: ACJfBovRFisr29Uc4/Ex+sr4CisKpNUphSf3LpM8buaBwK+FiZHz3vA+VNWdqPVBd7NerR4blDp/TSK7QauMIQg0ZHo= MIME-Version: 1.0 In-Reply-To: <1515184364.29312.188.camel@amazon.co.uk> References: <1515058213.12987.89.camel@amazon.co.uk> <20180104143710.8961-1-dwmw@amazon.co.uk> <1515160619.29312.126.camel@amazon.co.uk> <1515170506.29312.149.camel@amazon.co.uk> <20180105164505.xpw5pefxsyu3z56e@pd.tnic> <1515172353.29312.161.camel@amazon.co.uk> <1515184364.29312.188.camel@amazon.co.uk> From: Brian Gerst Date: Fri, 5 Jan 2018 16:11:07 -0500 Message-ID: Subject: Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support To: "Woodhouse, David" Cc: Linus Torvalds , "bp@suse.de" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "tim.c.chen@linux.intel.com" , "tglx@linutronix.de" , "ak@linux.intel.com" , "riel@redhat.com" , "keescook@google.com" , "gnomes@lxorguk.ukuu.org.uk" , "pjt@google.com" , "dave.hansen@intel.com" , "luto@amacapital.net" , "jikos@kernel.org" , "gregkh@linux-foundation.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, Jan 5, 2018 at 3:32 PM, Woodhouse, David wrote: > On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote: >> >> Yes, I would suggest against expecting altinstructions to have >> relocation information. They are generated in a different place, so.. >> >> That said, I honestly like the inline version (the one that is in the >> google paper first) of the retpoline more than the out-of-line one. >> And that one shouldn't have any relocation issues, because all the >> offsets are relative. > > Note that the *only* issue with the relocation is that it pushes me to > use X86_FEATURE_NO_RETPOLINE for my feature instead of > X86_FEATURE_RETPOLINE as might be natural. And actually there's a > motivation to do that anyway, because of the way three-way alternatives > interact. > > With the existing negative flag I can do > > ALTERNATIVE_2(retpoline, K8: lfence+jmp; NO_RETPOLINE: jmp) > > But if I invert it, I think I need two feature flags to get the same functionality — X86_FEATURE_RETPOLINE and X86_FEATURE_RETPOLINE_AMD: > > ALTERNATIVE_2(jmp, RETPOLINE: retpoline, RETPOLINE_AMD: lfence+jmp) Another way to do it is with two consecutive alternatives: ALTERNATIVE(NOP, K8: lfence) ALTERNATIVE(jmp indirect, RETPOLINE: jmp thunk) This also avoids the issue with the relocation of the jmp target when the replacement is more than one instruction. -- Brian Gerst