From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516652725; cv=none; d=google.com; s=arc-20160816; b=eU7qCBYyaNMG2ujgJ/K4jM4QqV/nYg7nprPdi6mNYhE7NhcNi7GbUAnnGul9QeNEHu cU/umIqaJOtsZgrLZ39HpJW3zT5xE0mpszp7PjuCeRKNwFC7/0qsHcIdjz/M0rzsc+I2 AMH4D58DILIG+hE8Mt3eO6acmz7D8RTjpLEHuiFbGtzZBESkEV4nbyPal6/AIE1z2322 CuMFt7BRFVJM/ECmdrGQxZb5rofywCgmbGEEWJVfg3u38HZQ2N0ltQawV5ZvzuyYLNcG EhIVtMvG8gl++nZzr4O6efE4d60NyIZY97gnrH9iJCtfr9mznMRNHMzqRvseE66AOJpL AJyQ== 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:sender:dkim-signature:arc-authentication-results; bh=9f5zBXaXd3TLhluLMZCR0puRviJ+yAaDe+sL2OmGCI4=; b=rrp3Bjn5hNt53A1DsAA++nu/iTgMdC9yM6bjMB/5EpfF+5h9mc8gaqbhVvhgzpXM0o m5C+Itb2igD/Oo4Q6drbUyKB1Az9x/l0XuVZiFeNpQRrgnTOBsMoecNdrFq9apcr+kHo D/i0K/PS2YhsOy/6Yd79ZfDohnUg4hRgAzBOb/rFKgOrQj/o0t+bXcK+wV5jHQKDcNop zDqPCcsxmE+hwFQWaB/xoMWFSoIs4xxr1K7OiMbmhTWZjr2iDn9XNikSUb0e0FvrNZqI gKnRYYX3++q7KWyKrCOw3yv9pb4MWBiKZbne1VsfyGQYGRfkLUOQzmnLHEOK1ijIzjHe rkig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QD0+6Tex; spf=pass (google.com: domain of groeck7@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=groeck7@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QD0+6Tex; spf=pass (google.com: domain of groeck7@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=groeck7@gmail.com X-Google-Smtp-Source: AH8x227SQ8n5Ajkl2cABr7dw0uaUfi9fub1RBJttb3h7uvU8ElaTWIBiLX5N0BDItzA4ubixQ4ajow== Sender: Guenter Roeck Date: Mon, 22 Jan 2018 12:25:22 -0800 From: Guenter Roeck To: David Woodhouse Cc: Josh Poimboeuf , 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: <20180122202522.GA29081@roeck-us.net> References: <1515707194-20531-3-git-send-email-dwmw@amazon.co.uk> <20180118190931.GA27143@roeck-us.net> <20180118193315.zrrya7qo6kf7pmzp@treble> <20180118194112.GA28449@roeck-us.net> <1516649644.9521.61.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: <1516649644.9521.61.camel@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589334210253041473?= X-GMAIL-MSGID: =?utf-8?q?1590325648204217046?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hi David, On Mon, Jan 22, 2018 at 07:34:04PM +0000, David Woodhouse wrote: > On Thu, 2018-01-18 at 11:41 -0800, Guenter Roeck wrote: > > > > > Not sure, does your gcc have retpolines?  Give me your .o file and I can > > > diagnose it. > > >  > > Yes, it does, only it is the gcc from the Google toolchain which may > > generate different code than the upstream version. > > > > I attached an affected object file. Please let me know if there is anything else > > I can do to help. > Disassembly of section .text.__x86.indirect_thunk: > > 0000000000000000 <__x86.indirect_thunk>: >    0: e8 04 00 00 00        callq  9 <__x86.indirect_thunk+0x9> >    5: f3 90                 pause   >    7: eb fc                 jmp    5 <__x86.indirect_thunk+0x5> >    9: 48 8d 64 24 08        lea    0x8(%rsp),%rsp >    e: c3                    retq    > > That has the old-style CET-incompatible retpoline in a COMDAT section > in the .o file. What compiler options are being used for that? The > kernel should only use retpoline if GCC supports both of > -mindirect-branch=thunk-extern and -mindirect-branch-register, and this > compiler is doing *neither* of those.  It uses "-mindirect-branch=thunk -mindirect-branch-loop=pause -fno-jump-tables", though I don't know if that even exists in upstream gcc (it is the gcc use for Chrome OS builds). I'll pass your feedback to our compiler team. Either case, I think it is less than optimal that objtool crashes with _any_ object code. Thanks, Guenter