Received: by 10.223.176.46 with SMTP id f43csp3287075wra; Mon, 22 Jan 2018 11:28:38 -0800 (PST) X-Google-Smtp-Source: AH8x225qGknKEunIyyIm3JcxunFJecVGbpVMH8UGpts1ZnH6klLYRmMo7bIF4X+odJ0bgIunc+Zi X-Received: by 10.36.95.72 with SMTP id r69mr10431145itb.48.1516649318243; Mon, 22 Jan 2018 11:28:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516649318; cv=none; d=google.com; s=arc-20160816; b=X0S5GTVyDvJyM0S7NG+tL3rO/jJr88DKFkr6Fz3Uu3kEPVpDtBN2T1WszWBIb9E7lm vO0J5PdhCVrl5DbOGBcGCxgXf0pAopMFGoffJ7HJwGz8RRc2Gz1Xq3HGHczdEGE3zTMh sUF2bvSorpN9cA+Zmm++GdHs+WmfMTDwKRanXtheh77RMKMhivWDyMz7gg1cVOBNTU1t Rzqda19IOjp0ufiRqEeOHkczDWcWZWmJpym1PAEIb1kDjVmrRM/jDxc7A0HaS00MRrbR vDk2fCBEozOV4Z4MSQ/+nmMunzh98JoOzxFl7zacQ9vp1k4K44CKGTIbW6DXYfDCpoVK 2rpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=C3pdhKT9HLcrqqNkhyiLbdF7ZMRcTU/5NyZS3AC/p8g=; b=EFTU5M7D3zmXU9HCblVw/48zFn95kJUOQYimSBrIs4GyRtPzyhlU9e5rIEREh5nGBC ztn13RZk6uFxgjU48f+XL8sEFubexoGmFY5P+QBqEbCX1ZieB4MUl/pWV6mFXyaF9gjc yP+6KlBRpVtS2A6NELVsmItj6jZYj4185pkcEfPWxWA/AzReGVM40rs/1Irn1+E1Uep6 l6qIQw/oAPu0Cmu9wMBD73d9hYkoaPkidSyFrYONzFO7ID7E7QeRBFNUGb+Z6hBqXWWz diHy6DKCqExpNLjwDTQfZOOig5iNvnArZD4dEFwvwrKDQJc9pdAw1YviggLJzWxMq00H /8rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=G/8F9HcL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 2si6481633itf.103.2018.01.22.11.28.25; Mon, 22 Jan 2018 11:28:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=G/8F9HcL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751110AbeAVT1d (ORCPT + 99 others); Mon, 22 Jan 2018 14:27:33 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:43619 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbeAVT1c (ORCPT ); Mon, 22 Jan 2018 14:27:32 -0500 Received: by mail-pf0-f193.google.com with SMTP id y26so7834176pfi.10 for ; Mon, 22 Jan 2018 11:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C3pdhKT9HLcrqqNkhyiLbdF7ZMRcTU/5NyZS3AC/p8g=; b=G/8F9HcLApiSNb1F9t/DzsUKBKtQXIFLDwVmVgiAkkj4iMm5ZaCi3PBIl0EGKpRal7 EmA2qzjUhObXw9s3v4R6wZQmahK0/IW//PvvRz75b7SGUlJJL6HXn2zhRA8y7vHqmQMG Hhx2+QDtAq/x34p/OAeCtP/fGclR8gTwAjAR/ZJI3efqeqaMZHTI0H0yHsZQDMY1laoA Yxk+kvIze31baoe6k3WwNbAgMDa967W3n1GPctIpwTjDIGkxfarpRoZ4vn31/r8g0XxN cnUYb1efkCmg75j07HR7MnRVyfBp4mvC1OcPu8sHV+51Y7C31EINxp7uNtaytIhHJ6vb fO+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=C3pdhKT9HLcrqqNkhyiLbdF7ZMRcTU/5NyZS3AC/p8g=; b=qarjML3EE3V+lNDeI6ovrXGkTezkXkjyAeCvEErGHEod0r7rrMCXX3RE28+Zud7spO yPZHzyzg3cDddnMkRs1+i6zKwfE9ccOwLqcMXR3InomWnWQ0tVFQt54cVA+8PamQD6ia IT8q94b+1+ciLDj9ZlaMc17O16/wBFq95Uk2f581t5zVAJQ88nwcROFMdv6Q66rWqJV1 zCZCboBb05HziSzldRJcPLmQMouE/1HXchLmN36p2h/1WLxBnFRwkr+jRW8gaCEjLCU2 lXebkuy94nn+HZh+XSvcEk81XdO/+xgaL/t/dUV0woht33aQT0ymr4hzgTppnQp+wAln 4hbA== X-Gm-Message-State: AKwxytfFNRq5lM5iB68mRSHoN3f7n2oKsvAZgylGPLiZEzei5yRIRytI iEj9Ra/kcTTQYomxPDi24qo= X-Received: by 2002:a17:902:44c:: with SMTP id 70-v6mr3956951ple.221.1516649251768; Mon, 22 Jan 2018 11:27:31 -0800 (PST) Received: from localhost (108-223-40-66.lightspeed.sntcca.sbcglobal.net. [108.223.40.66]) by smtp.gmail.com with ESMTPSA id o7sm24538953pgp.18.2018.01.22.11.27.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 11:27:30 -0800 (PST) Date: Mon, 22 Jan 2018 11:27:29 -0800 From: Guenter Roeck To: Josh Poimboeuf 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: <20180122192729.GA28236@roeck-us.net> References: <1515707194-20531-3-git-send-email-dwmw@amazon.co.uk> <20180118190931.GA27143@roeck-us.net> <20180118193315.zrrya7qo6kf7pmzp@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180118193315.zrrya7qo6kf7pmzp@treble> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 18, 2018 at 01:33:15PM -0600, Josh Poimboeuf wrote: > 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. > Any updates ? I reverted thee offending patch from our latest stable tree merge, but that doesn't really solve the issue. Thanks, Guenter