This is the mail archive of the
mailing list for the binutils project.
Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Cary Coutant <ccoutant at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Mark Wielaard <mjw at redhat dot com>, Jiong Wang <jiong dot wang at foss dot arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, GDB <gdb-patches at sourceware dot org>, Binutils <binutils at sourceware dot org>
- Date: Thu, 1 Dec 2016 10:42:37 +0000
- Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <20161111193859.GJ3541@tucnak.redhat.com> <email@example.com> <20161115161817.GL3541@tucnak.redhat.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20161116140218.GU3541@tucnak.redhat.com> <CAJimCsFXARZ4OBr01yvpLEybdGcKq4D5QD99mRdPqS2yCuTtUg@mail.gmail.com>
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):
> 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?
> On Wed, Nov 16, 2016 at 6:02 AM, Jakub Jelinek <firstname.lastname@example.org> 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