From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x22537P31YweJByQEWMLPKnsqoV9HCjhM5e6hQr/QoYUEcEWFMulmCZdE/I117v0Ha4mNMNtB ARC-Seal: i=1; a=rsa-sha256; t=1517247850; cv=none; d=google.com; s=arc-20160816; b=BJ1AbDCu+Rre4TZtCkA+m+yHCy8YZFXefWInTiGs7VSAEaoC8TiR1N8wLooGXLmcKH QeLyyV3mbycSMu36vJnQSnsDdBSlwfj2EsA4vhQfR6wNTvs4vJbm1pSMfI5iKlgoX9KE +UCYNXDwEXODJ5zC1pF6FrVUCdiOTcutwELJkBjxdyX8Q91ZPgifMkIi6vD+WYivjXvw ylmKtPPVMsAIpSgaOMC022cfe8XRaEtsU8FDujkvjm5w40arhByzDaUtU6lagjOL5hYd Oefwcr3Me3lPnfsGKJeXrn0iCBNMkm8cejPqF1gPWWpaNjwY8Up19c0QmHMpvvvrPq4R Nr5A== 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:dkim-signature:arc-authentication-results; bh=6ZH+CL/LWhL3RW9c7sBwjC8Y/pTTf504za91qEa0ejw=; b=iVe7j0QS9+C7zeXn5kMWfDfohBE3yOr8MoVH7HuN9ruLz9YRkF+3QBnkw9zE2tAAGu Bby1rwQItQTB+4NhhMrMUQZ5hjfM+GUq6luSnPOA3On+d45y+05f2QvLC+efwd3e7wp6 UnZVDxED13ePdI8DVQhETpZnxGIoVxkcPW1qo8WFpGAiWF/Kkh0lQ15wYxHGOUWPYntK GjDdgWXTXla/1yKqQ108DA3oh2rWF+PXMj8AxyOs7ImVu7yGS+FyjtyHu17Ekz5shk5o bxYeK7Fmb4d3VzE6NyQxUwUg9O9KcK+jnr/7Qj3Xr66d1DL4+oTyScMrCTC1skcRqVxo 5pgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20170209 header.b=rS5srYPP; spf=pass (google.com: best guess record for domain of peterz@infradead.org designates 65.50.211.133 as permitted sender) smtp.mailfrom=peterz@infradead.org Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20170209 header.b=rS5srYPP; spf=pass (google.com: best guess record for domain of peterz@infradead.org designates 65.50.211.133 as permitted sender) smtp.mailfrom=peterz@infradead.org Date: Mon, 29 Jan 2018 18:44:03 +0100 From: Peter Zijlstra To: David Woodhouse Cc: Thomas Gleixner , Josh Poimboeuf , linux-kernel@vger.kernel.org, Dave Hansen , Ashok Raj , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Andrea Arcangeli , Andi Kleen , Arjan Van De Ven , Dan Williams , Paolo Bonzini , Jun Nakajima , Asit Mallick , Jason Baron Subject: Re: [PATCH 04/24] x86,nospec: Annotate indirect calls/jumps Message-ID: <20180129174403.GH2228@hirez.programming.kicks-ass.net> References: <20180123152539.374360046@infradead.org> <20180123152638.217996936@infradead.org> <1516961987.30244.178.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1516961987.30244.178.camel@infradead.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590397853592913916?= X-GMAIL-MSGID: =?utf-8?q?1590949681668055885?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Jan 26, 2018 at 10:19:47AM +0000, David Woodhouse wrote: > On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote: > > Annotate the indirect calls/jumps in the CALL_NOSPEC/JUMP_NOSPEC > > alternatives. > > > > > > Signed-off-by: Peter Zijlstra (Intel) > > Reviewed-by: David Woodhouse > > However... > > > >  /* > > + * This should be used immediately before an indirect jump/call. It tells > > + * objtool the subsequent indirect jump/call is vouched safe for retpoline > > + * builds. > > + */ > > +.macro ANNOTATE_RETPOLINE_SAFE > > + .Lannotate_\@: > > + .pushsection .discard.retpoline_safe > > + _ASM_PTR .Lannotate_\@ > > + .popsection > > +.endm > > Didn't I just see one of those in patch 3? So this makes two... > > > > > @@ -143,6 +155,12 @@ > >   ".long 999b - .\n\t" \ > >   ".popsection\n\t" > >   > > +#define ANNOTATE_RETPOLINE_SAFE \ > > + "999:\n\t" \ > > + ".pushsection .discard.retpoline_safe\n\t" \ > > + _ASM_PTR " 999b\n\t" \ > > + ".popsection\n\t" > > + > >  #if defined(CONFIG_X86_64) && defined(RETPOLINE) > > ... three. > > Now, I did briefly toy with the idea of using a .macro from both > __ASSEMBLY__ and inline asm, making the latter work by means of  > asm(".include \"asm/nospec-branch.h\"); > > In the end I just ended up with the __FILL_RETURN_BUFFER CPP macro > which is used from both by other tricks. > > Can we look at doing something like that, please? I'll try. The paravirt one might be tricky, I always end in header-hell with that thing.