Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1758970yba; Thu, 25 Apr 2019 05:23:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqz0KH7DaKYwobYJBX/0rYBcsgJDKW0/E8oMnxuOGotKv105JRd92hfrkSLZ/J/BoPA1iwoK X-Received: by 2002:a62:a219:: with SMTP id m25mr39989573pff.197.1556194989082; Thu, 25 Apr 2019 05:23:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556194989; cv=none; d=google.com; s=arc-20160816; b=iq1B0SvpVv1vruDbOxU9RuLlWK4+MfjbV3aAVzIGyFQPNALho7sl82GMhhM+7+W7i/ ABVRZIkgeR3c+ViVbc8cHNY/Tf5ZJw1788oMmdMXVzEFFyNSjAicGZiTefKKiZRzw/ix VmY5geLs31/JAoiBsxnVtLZDvLHRvZrs7W9xHbiZphY8NepZoOHNe3jV0CA8p30OS6+E Ik+eduRtQY8GIe0AFYX9RsTBUzxQgQv9Mcj5qrohNGdMuXVkelzi3roPzGO3yd6X9O46 ipB0Fp+XiAzaGMDOdZzKuLKJmj+x/8Ztzal29rGRLXHvvhM77rpROtRXcDYsIAQZHnfY ksyA== 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; bh=sA64SEnRlKcPxfGZbt5NjWRkUkhVgmJCuZ+TFzTB++k=; b=pR4kN5Hj7eYHc4yHhTVJRYVw2Ao6LgKwe2kgjiAaO9rHx+XeaYWEUFhnFMAY+59T9w AEKmlJ1nTZf5mbADuX6bO1ardnRr9Do58DsN1QDfIIb07kx/8+8nWYOAIAHJRhhCGxAa gj6kRIrga5mYu5GZ0xM7n5hrq6BAzJpsrtblrKhil9mqIdMRp1c+Nmik6RvauiisYjuM fC2L8vDFF+wASvyd8vKYWCr8EjX/j6h3wkhA7mYg76ZwsOxTvVkDivEL2Yma+AKpC+lv 1bCrVgCErN2FD/4YWQmmmyuLYFtCIz4qHA1K2VUTph5lfbZL2Uw3CZRbcwjWSwB6CZvQ aSXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=2gypBO3n; 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 c22si7171974pfr.15.2019.04.25.05.22.52; Thu, 25 Apr 2019 05:23:09 -0700 (PDT) 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=@infradead.org header.s=merlin.20170209 header.b=2gypBO3n; 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 S1729367AbfDYIdZ (ORCPT + 99 others); Thu, 25 Apr 2019 04:33:25 -0400 Received: from merlin.infradead.org ([205.233.59.134]:48294 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726272AbfDYIdY (ORCPT ); Thu, 25 Apr 2019 04:33:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sA64SEnRlKcPxfGZbt5NjWRkUkhVgmJCuZ+TFzTB++k=; b=2gypBO3nHvA0R+JYarJCymfk0 PZjTr/t+QOUrMNmsZT4xwbfMLNhlMjMbn6wSca+OUO3TAM/1Wd46V0xKQYIUFWrP2Ud4V7YteDXHO 5Y6C3fJ95Dw4qx/p7dQUKfJlNYlRsx1wWY+okqDrfqrX5I02mqh1UZQoX6YQ0cuecFTV7cXmDVi3M AyilxPCRvBsYzMQbdo1Gu7xeN8iO/Y5yWUYX9wTN6xqebZHKAjHMSYYPv9HnQXKAGehDv3tyq4Yus N54OzSu0A/zKZHChhn7s8JVQyVULU+mH5QY6RA/7Mk2X4N2KAi3Hqp0RQVcoO1gm0JulywhOpQxcl cMGizLfpg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJZon-0001Fs-Me; Thu, 25 Apr 2019 08:33:21 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3B75B203E8871; Thu, 25 Apr 2019 10:33:20 +0200 (CEST) Date: Thu, 25 Apr 2019 10:33:20 +0200 From: Peter Zijlstra To: Raphael Gault Cc: Josh Poimboeuf , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , Will Deacon , Julien Thierry Subject: Re: [RFC 3/6] objtool: arm64: Adapt the stack frame checks and the section analysis for the arm architecture Message-ID: <20190425083320.GK4038@hirez.programming.kicks-ass.net> References: <20190409135243.12424-1-raphael.gault@arm.com> <20190409135243.12424-4-raphael.gault@arm.com> <20190423203627.mwnaknit7cvr3l5l@treble> <20190424165640.5yeg2yicl7ej7g3i@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 25, 2019 at 08:12:24AM +0000, Raphael Gault wrote: > The motivation behind this is that the `br ` instruction is a > dynamic jump (jump to the address contained in the provided register). > This instruction is used for sibling calls but can also be used for > switch table. I use this to differentiate these two cases from one another: > > Generally the `adr/adrp` instruction is used prior to `br` in order to > load the address into the register. What I do here is go back throught > the instructions and try to identify if the address loaded. Yikes, be very careful with simply going back on the instruction stream. The problem case would be something like: adr ... b 1f ... b ... 1: br ... In that case, simply going backwards from 1 will not yield the desired result. At some point I did a pass storing all the fwd jumps in their destination and used that to 'rewind' the instruction stream, but that wasn't very pretty either. The best way might be to, while doing validate_branch() keep a state table of all most recent ADR(P) instructions and when encountering BR check that state to see what it really is. We currently don't do dynamic insn->type, but it shouldn't be too hard (famous last words of course).