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 <ja...@redhat.com> 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
