From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x22698Mhl/HxxZDA9Q90LnryoY8rtQZUkuBllWs1PBuQdQsSUd1hJ/SG08DuX3YrjglcQswuW ARC-Seal: i=1; a=rsa-sha256; t=1516893032; cv=none; d=google.com; s=arc-20160816; b=P5N0V87vGvSGGUogMs70tMcAHDTwSmaiDRS+uMmExxI6Sd98oBhxl3FlkiKxicBIy9 gx2hZWlw/BT4flHXKiRRyuEWoWIzSPBQ7ozKmqQud6TKx7022NdX4fMC1bvUANEr4w7J nDdfeXwwVxXRcWE2rSqBkecrvF3kGrKih5R+ajxPY9HLd+A85jbAhKr61Euxsf5WmrOp Mxw6/5VJFLhAX2MHg2W9usGZxTETqMpGbnzEklpAGnxnphL8Mkiu1QC8/GlHo9rZdaR2 R1HlHmmR09qQNAH4Rwmj+o4KqwO5CfkqAx5gT6llbLGGi2fSOYkse78l26mE6brAzoE9 rXuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=GtIQLTQAv+n+KvSTgEXzpmGzcLLato+HLesnLR8qxAY=; b=uzCt5KeDKJ1Zwe2Fisf5QrAkMm88AU0qJ5bnqAsOkD+E5IZVKwHeSj/XdoEHMdh1fs XTaNk72DQV3nuoVlHBL2/tdNlLwqiSeAeU4HwIyLY8QCe6PcNhkXrA5Gkt4g7CjCWOUo 30a5iNgI5aHfWb4OIJXtbpsAiGmVISlW4BbNImkE8x/pF+vpO2Xg2asCQrV+qwjNaLZY pFKqy/WGcxYyxZ1qLvmvRe9I9aqtRyCqy6eQ8pBs342Bgdw5yMqAkDOnASoHd/k3E8sU xeRXv216sO6np3EGWkb2epZc3ccrmdIbngVQ2bTe7b6th9VaENXtuOoA6A07ix0vk6G6 CaNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of jpoimboe@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jpoimboe@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of jpoimboe@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=jpoimboe@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Thu, 25 Jan 2018 09:10:24 -0600 From: Josh Poimboeuf To: Borislav Petkov Cc: David Woodhouse , 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, 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: <20180125151024.bidjr26r667vs7h5@treble> References: <1515755487-8524-1-git-send-email-dwmw@amazon.co.uk> <20180125120743.ey32gvl5mjam4r2s@pd.tnic> <1516882849.30244.94.camel@infradead.org> <20180125124554.vdx7rrnfrxrzl2ng@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180125124554.vdx7rrnfrxrzl2ng@pd.tnic> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589334225298273984?= X-GMAIL-MSGID: =?utf-8?q?1590577628667817174?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, Jan 25, 2018 at 01:45:54PM +0100, Borislav Petkov wrote: > > > +/* 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. Huh? GCC doesn't even look inside the inline asm. That's why we had to implement ASM_CALL_CONSTRAINT. And the seg fault is objtool's way of telling you you need a ANNOTATE_NOSPEC_ALTERNATIVE above the alternative ;-) (I know that's not the best answer, will fix it soon.) -- Josh