From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224bhVL0xbG+jH3K5SIBtASPyLb/Qv8sII7qwPhHXdNV8SPSDtHQTZWmmniOAaqoCfpQCWgr ARC-Seal: i=1; a=rsa-sha256; t=1516884364; cv=none; d=google.com; s=arc-20160816; b=FzIRd+al4oCcndZFUgTumZRHzBrqcdTVkJQrOOMRtcy+eqrWfE6f9Iam/6DYehHX4z H/kvX6lRwpsMvxVMKtgBh2MNokjwcYXtykPhS1a2+zAMi5AkB9h+Tctos5ycJZTurXHb NngIB8iOagm9tPV0kT7XKHVkd6YD+5zqjiUS1NEr4aIu5u3KZbNuICwLFsPP61MaPIOe ooOF83yx0TErgXULDlAEsUvTklBym6sDNQP4prScd0vsSpaUOsUYC59jyoxwknaah/Lz YjPNjTzhSQXFuAvnBQdUeHBa5auSyF8Mta03N3oMZj9Bh062xsaN4A3aVCFItn2lGO3p TUjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=rdP00KTXmxsdr7LvNoUIYElMvJDCNO+ZkCud7nCpal4=; b=rSzaFhp11TKKBudv6anPbEr7H6YkuDzvutKIdcgxE7uakO/W09wI/wD5WvBP1fZwLx YM5mOtYEzheEuWeC00/2QMQJZuCc6+9DVSA5MnAxkeIY3VTSe7DA7digBXsLvZK2nIPT FkXXTlFZzeqQu2H3u4nzOuqI2gROKE9mWr2nZK4aCBTGMZ9faODfImuPFIWP+PW+mShx wPubqlUbBEdmoICistkmMxrkfEVtuniCb4xzFDEDNOcq3iasIGfZvhJgxJZ8XXqZT8M0 cI2fAurAgqM+2nkAp8U1MkGJWL5DeJ/iTOMVzseN/9BkgCdCRRGTGlqqkXUT3Jif3akn ijmA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of bp@alien8.de designates 2a01:4f8:190:11c2::b:1457 as permitted sender) smtp.mailfrom=bp@alien8.de Authentication-Results: mx.google.com; spf=pass (google.com: domain of bp@alien8.de designates 2a01:4f8:190:11c2::b:1457 as permitted sender) smtp.mailfrom=bp@alien8.de Date: Thu, 25 Jan 2018 13:45:54 +0100 From: Borislav Petkov To: David Woodhouse Cc: tim.c.chen@linux.intel.com, pjt@google.com, jikos@kernel.org, gregkh@linux-foundation.org, dave.hansen@intel.com, mingo@kernel.org, riel@redhat.com, luto@amacapital.net, torvalds@linux-foundation.org, ak@linux.intel.com, keescook@google.com, jpoimboe@redhat.com, peterz@infradead.org, tglx@linutronix.de, hpa@zytor.com, linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/pti] x86/retpoline: Fill return stack buffer on vmexit Message-ID: <20180125124554.vdx7rrnfrxrzl2ng@pd.tnic> References: <1515755487-8524-1-git-send-email-dwmw@amazon.co.uk> <20180125120743.ey32gvl5mjam4r2s@pd.tnic> <1516882849.30244.94.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516882849.30244.94.camel@infradead.org> User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589334225298273984?= X-GMAIL-MSGID: =?utf-8?q?1590568538933386163?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, Jan 25, 2018 at 12:20:49PM +0000, David Woodhouse wrote: > I haven't had lunch yet, so I don't feel queasy Oh, I caught you on time then :-) > and I'm vaguely interested... *why* does it break kABI? Kernels < 4.1 don't have the insn padding I did back then so when one tries to backport this, struct alt_instr size changes. Fun. > > +/* Like alternative_io, but for replacing a direct call with another one. */ > > +#define alternative_void_call(oldfunc, newfunc, feature, input...) \ > > + asm volatile (ALTERNATIVE("call %P[old]", "call %P[new]", feature) \ > > + : : [old] "i" (oldfunc), [new] "i" (newfunc), ## input) > > But you aren't doing the call at all in the other case, and > alternatives *always* handled the case where the first 'alternative' > instruction was a branch, didn't it? > > So couldn't it just be alternative(nop, call __fill_rsb_func)? > > But I still don't understand why it matters. You need for both to be CALL instructions there so that gcc can manage the callee clobbers properly - i.e., recognize that there's a function call there. Otherwise you need to do uglies like the hunk in arch/x86/Kconfig in d61931d89be5 ("x86: Add optimized popcnt variants") which I killed later after all as it broke profiling and other tools. And besides, calling a NOPpy function on CONFIG_RETPOLINE=n is the least of our troubles. Also, the installations running CONFIG_RETPOLINE=n are going to be a very very very small number. > > +void __fill_rsb(void) > > +{ > > + unsigned long loops; > > + > > + asm volatile (__stringify(__FILL_RETURN_BUFFER(%0, RSB_CLEAR_LOOPS, %1)) > > +       : "=r" (loops), ASM_CALL_CONSTRAINT > > +       : : "memory" ); > > +} > > +#endif > > The out-of-line function should be __clear_rsb() if it's using > RSB_CLEAR_LOOPS, and __fill_rsb() if it's using RSB_FILL_LOOPS. I think > we're only using one right now but Andi at least is posting patches > which use the other, as part of the Skylake clusterfuck. Ok. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.