From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53022 invoked by alias); 1 Dec 2016 10:42:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 52992 invoked by uid 89); 1 Dec 2016 10:42:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=coutant, Coutant, Cary, H*i:sk:CAJimCs X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Dec 2016 10:42:41 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 548F4165D; Thu, 1 Dec 2016 02:42:40 -0800 (PST) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 105F83F24D; Thu, 1 Dec 2016 02:42:38 -0800 (PST) Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space To: Cary Coutant , Jakub Jelinek References: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com> <20161115161817.GL3541@tucnak.redhat.com> <5896be40-51de-55f7-f4a1-4c5af7ff9aec@foss.arm.com> <1479304496.14569.256.camel@redhat.com> <20161116140218.GU3541@tucnak.redhat.com> Cc: Mark Wielaard , Jiong Wang , gcc-patches , GDB , Binutils From: "Richard Earnshaw (lists)" Message-ID: Date: Thu, 01 Dec 2016 10:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00020.txt.bz2 On 30/11/16 21:43, Cary Coutant wrote: > How about if instead of special DW_OP codes, you instead define a new > virtual register that contains the mangled return address? If the rule > for that virtual register is anything other than DW_CFA_undefined, > you'd expect to find the mangled return address using that rule; > otherwise, you would use the rule for LR instead and expect an > unmangled return address. The earlier example would become (picking an > arbitrary value of 120 for the new virtual register number): > > .cfi_startproc > 0x0 paciasp (this instruction sign return address register LR/X30) > .cfi_val 120, DW_OP_reg30 > 0x4 stp x29, x30, [sp, -32]! > .cfi_offset 120, -16 > .cfi_offset 29, -32 > .cfi_def_cfa_offset 32 > 0x8 add x29, sp, 0 > > Just a suggestion... What about signing other registers? And what if the value is then copied to another register? Don't you end up with every possible register (including the FP/SIMD registers) needing a shadow copy? R. > > -cary > > > On Wed, Nov 16, 2016 at 6:02 AM, Jakub Jelinek wrote: >> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: >>> On Wed, 2016-11-16 at 10:00 +0000, Jiong Wang wrote: >>>> The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref were >>>> designed as shortcut operations when LR is signed with A key and using >>>> function's CFA as salt. This is the default behaviour of return address >>>> signing so is expected to be used for most of the time. DW_OP_AARCH64_pauth >>>> is designed as a generic operation that allow describing pointer signing on >>>> any value using any salt and key in case we can't use the shortcut operations >>>> we can use this. >>> >>> I admit to not fully understand the salting/keying involved. But given >>> that the DW_OP space is really tiny, so we would like to not eat up too >>> many of them for new opcodes. And given that introducing any new DW_OPs >>> using for CFI unwinding will break any unwinder anyway causing us to >>> update them all for this new feature. Have you thought about using a new >>> CIE augmentation string character for describing that the return >>> address/link register used by a function/frame is salted/keyed? >>> >>> This seems a good description of CIE records and augmentation >>> characters: http://www.airs.com/blog/archives/460 >>> >>> It obviously also involves updating all unwinders to understand the new >>> augmentation character (and possible arguments). But it might be more >>> generic and saves us from using up too many DW_OPs. >> >> From what I understood, the return address is not always scrambled, so >> it doesn't apply to the whole function, just to most of it (except for >> an insn in the prologue and some in the epilogue). So I think one op is >> needed. But can't it be just a toggable flag whether the return address >> is scrambled + some arguments to it? >> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >> way of scrambling starts here (if not already active) or any kind of >> scrambling ends here (if already active), and >> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >> to represent details of the less common variants with details what to do. >> Then you'd just hook through some MD_* macro in the unwinder the >> descrambling operation if the scrambling is active at the insns you unwind >> on. >> >> Jakub