From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBovCWMJZAHAFf1kUZkuCxTaVi4lIBQPYgn6kYv+/Pb5BqVVIUWQNBP3d2JDbg53CZ9MyVMGs ARC-Seal: i=1; a=rsa-sha256; t=1516304003; cv=none; d=google.com; s=arc-20160816; b=XTBcI1epCd9HJhmGykFhWZY1gPQpmfr1CjX4nWU/QiI1uSHAtHQZiuTUO9x3UFpBYw ubZkzRneviBoID48uJEGQ6f84igLnSw+bw2JHfCfi7OwFd/8HWkXpmgYLeg5DMfdu2wl Y7eUNl7YWLY1w73ZhFkpLvZJSckv1Yck71+mtTjgS2Q+GaQIDxsYlOUfTM45mkrs2Phy /AK2HHI22TCgcibsB7eFIF/oSuD3HQGugfHIE3+5t41RaAXP0qE5o4Vp4eGYB+e1pAoL qxheJbGg0kmBzovY3aQowy5keXk1kVE1SJZEuPbT5pfCcDYL7DRQnWaSECdVxsTFXh3v mARg== 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=EyGXq5pKH1OALapeRx0Flfp0PKIJl7DmBtPtGoL6Wr8=; b=G0yfPjfkaCeXNQVj08x/TicRcRCnwndf3ucZqgxMD1d5HqrurPNSKAbpqq+zCuhU8a VZCyWbA7/4oY3LqD9DtcqB0cfze9RyaqECEvXtEhbg0kD09v34uDEAb7mKLFczdCVzeV vMmu9PuoPckd95XlgKlsy/rcRzfQwDVJg3OoEfKZ3cDdHHYb6TbPN8Ym2w33JQst0gDo C8mODZ4P/WOQudCdzOuj/PaXXOXd/qIow6EzPmMZ6RHFOP9Cb9oMZMWKDy/LbSDZ+W2y XYiuIfjhMt5oPHJrtq0GMH1oc3PhJSOVz5FMW18kOuEj6lzgeuWzOWYhnH0womEKcgu8 2xWw== 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, 18 Jan 2018 13:33:15 -0600 From: Josh Poimboeuf To: Guenter Roeck Cc: "Woodhouse, David" , Andi Kleen , Paul Turner , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , tglx@linutronix.de, Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , gnomes@lxorguk.ukuu.org.uk, x86@kernel.org, thomas.lendacky@amd.com Subject: Re: [v8,02/12] objtool: Allow alternatives to be ignored Message-ID: <20180118193315.zrrya7qo6kf7pmzp@treble> References: <1515707194-20531-3-git-send-email-dwmw@amazon.co.uk> <20180118190931.GA27143@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180118190931.GA27143@roeck-us.net> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589334210253041473?= X-GMAIL-MSGID: =?utf-8?q?1589959986830204352?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, Jan 18, 2018 at 11:09:31AM -0800, Guenter Roeck wrote: > Hi folks, > > On Thu, Jan 11, 2018 at 09:46:24PM +0000, Woodhouse, David wrote: > > Getting objtool to understand retpolines is going to be a bit of a > > challenge. For now, take advantage of the fact that retpolines are > > patched in with alternatives. Just read the original (sane) > > non-alternative instruction, and ignore the patched-in retpoline. > > > > This allows objtool to understand the control flow *around* the > > retpoline, even if it can't yet follow what's inside. This means the > > ORC unwinder will fail to unwind from inside a retpoline, but will work > > fine otherwise. > > > > Signed-off-by: Josh Poimboeuf > > Signed-off-by: David Woodhouse > > --- > > tools/objtool/check.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++----- > > tools/objtool/check.h | 2 +- > > 2 files changed, 57 insertions(+), 7 deletions(-) > > > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > > index de053fb..f40d46e 100644 > > --- a/tools/objtool/check.c > > +++ b/tools/objtool/check.c > > @@ -428,6 +428,40 @@ static void add_ignores(struct objtool_file *file) > > } > > > > /* > > + * FIXME: For now, just ignore any alternatives which add retpolines. This is > > + * a temporary hack, as it doesn't allow ORC to unwind from inside a retpoline. > > + * But it at least allows objtool to understand the control flow *around* the > > + * retpoline. > > + */ > > +static int add_nospec_ignores(struct objtool_file *file) > > +{ > > + struct section *sec; > > + struct rela *rela; > > + struct instruction *insn; > > + > > + sec = find_section_by_name(file->elf, ".rela.discard.nospec"); > > + if (!sec) > > + return 0; > > + > > + list_for_each_entry(rela, &sec->rela_list, list) { > > + if (rela->sym->type != STT_SECTION) { > > + WARN("unexpected relocation symbol type in %s", sec->name); > > + return -1; > > + } > > + > > + insn = find_insn(file, rela->sym->sec, rela->addend); > > + if (!insn) { > > + WARN("bad .discard.nospec entry"); > > + return -1; > > + } > > + > > + insn->ignore_alts = true; > > + } > > + > > + return 0; > > +} > > + > > +/* > > * Find the destination instructions for all jumps. > > */ > > static int add_jump_destinations(struct objtool_file *file) > > @@ -509,11 +543,18 @@ static int add_call_destinations(struct objtool_file *file) > > dest_off = insn->offset + insn->len + insn->immediate; > > insn->call_dest = find_symbol_by_offset(insn->sec, > > dest_off); > > + /* > > + * FIXME: Thanks to retpolines, it's now considered > > + * normal for a function to call within itself. So > > + * disable this warning for now. > > + */ > > +#if 0 > > if (!insn->call_dest) { > > WARN_FUNC("can't find call dest symbol at offset 0x%lx", > > insn->sec, insn->offset, dest_off); > > return -1; > > } > > +#endif > > This crashes for me in is_fentry_call(). > > Program received signal SIGSEGV, Segmentation fault. > is_fentry_call (insn=, insn=) at check.c:1113 > 1113 if (insn->type == INSN_CALL && > (gdb) info stack > #0 is_fentry_call (insn=, insn=) at check.c:1113 > #1 validate_branch (file=0x7ffffff7e440, first=0x7ffffff7e128, state=...) at check.c:1747 > #2 0x0000000000404bd3 in validate_branch (file=0x7ffffff7e440, first=0x7ffffff7e128, state=...) at check.c:1770 > #3 0x0000000000406783 in validate_functions (file=) at check.c:1933 > #4 check (_objname=0x6bb9d0 "", _no_fp=40, no_unreachable=4, orc=false) at check.c:2006 > #5 0x00000000004021c1 in handle_internal_command (argv=0x7fffffffe5c0, argc=4) at objtool.c:108 > #6 main (argc=4, argv=0x7fffffffe5c0) at objtool.c:131 > > This is not entirely surprising, since insn->call_dest is NULL and > is_fentry_call() doesn't expect that. > > How is this supposed to work ? What am I missing ? Not sure, does your gcc have retpolines? Give me your .o file and I can diagnose it. I intended to have an error msg instead of a seg fault for this situation, just haven't had a chance to improve that yet in the midst of all the hoopla. -- Josh