From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D541FC43381 for ; Fri, 8 Mar 2019 15:07:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AB2062133F for ; Fri, 8 Mar 2019 15:07:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726871AbfCHPHO (ORCPT ); Fri, 8 Mar 2019 10:07:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57572 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726631AbfCHPHN (ORCPT ); Fri, 8 Mar 2019 10:07:13 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6BBF0307D985; Fri, 8 Mar 2019 15:07:13 +0000 (UTC) Received: from treble (ovpn-120-61.rdu2.redhat.com [10.10.120.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 81D2360BE7; Fri, 8 Mar 2019 15:07:10 +0000 (UTC) Date: Fri, 8 Mar 2019 09:07:03 -0600 From: Josh Poimboeuf To: Peter Zijlstra Cc: Linus Torvalds , Thomas Gleixner , Peter Anvin , Julien Thierry , Will Deacon , Andy Lutomirski , Ingo Molnar , Catalin Marinas , James Morse , valentin.schneider@arm.com, Brian Gerst , Andrew Lutomirski , Borislav Petkov , Denys Vlasenko , Linux List Kernel Mailing , Dmitry Vyukov , Steven Rostedt Subject: Re: [PATCH 18/20] objtool: Add UACCESS validation Message-ID: <20190308150703.3jozuvj2crcxvlzp@treble> References: <20190307114511.870090179@infradead.org> <20190307115200.697533978@infradead.org> <20190307174135.GJ32477@hirez.programming.kicks-ass.net> <20190307184813.GL32477@hirez.programming.kicks-ass.net> <20190307202319.GD32534@hirez.programming.kicks-ass.net> <20190307204021.GE32534@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190307204021.GE32534@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Fri, 08 Mar 2019 15:07:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 07, 2019 at 09:40:21PM +0100, Peter Zijlstra wrote: > On Thu, Mar 07, 2019 at 09:23:19PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote: > > > Another thing I need to look at is why objtool only found memset_orig > > > (from __memset) but not memset_erms, which if I read the code right, is > > > a possible alternative there. > > > > Turns out we only look for sibling calls in the original instruction > > stream, not in any alternatives; which in general seems like a fair > > enough assumption. > > And while I'm looking at memset_64.S, why are memset_erms and > memset_orig global functions? At the very least they should be local, > and ideally not even functions. I think the only benefit is that they would show up better on stack traces, but that could also be solved by just making them local labels inside memset. Which is what I think they should be. The general rule is that ENDPROC is only used for callable functions, so yeah, I think the current setup isn't ideal, and also prevents objtool from properly doing the AC analysis as you pointed out earlier. -- Josh