lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 26 Jan 2022 06:08:59 -0800
From:   Dan Li <>
To:     Ard Biesheuvel <>
        Richard Earnshaw <>,, Kyrylo Tkachov <>,, Nick Desaulniers <>,,,,
        Richard Sandiford <>,,
        Peter Collingbourne <>,
        Sami Tolvanen <>,
        Kees Cook <>
Subject: Re: [PING^3][PATCH,v2,1/1,AARCH64][PR102768] aarch64: Add compiler
 support for Shadow Call Stack

On 1/26/22 03:09, Ard Biesheuvel wrote:
> On Wed, 26 Jan 2022 at 11:40, Dan Li <> wrote:
>> Thanks, Ard,
>> On 1/26/22 00:10, Ard Biesheuvel wrote:
>>> On Wed, 26 Jan 2022 at 08:53, Dan Li <> wrote:
>>>> Hi, all,
>>>> Sorry for bothering.
>>>> I'm trying to commit aarch64 scs code to the gcc and there is an issue
>>>> that I'm not sure about, could someone give me some suggestions?
>>>> (To avoid noise, I did't cc PING^3 [1] to the kernel mail list :) )
>>>> When clang enables scs, the following instructions are usually generated:
>>>> str     x30, [x18], 8
>>>> ldp     x29, x30, [sp], 16
>>>> ......
>>>> ldp     x29, x30, [sp], 16              ## x30 pop
>>>> ldr     x30, [x18, -8]!                 ## x30 pop again
>>>> ret
>>>> The x30 register is popped twice here, Richard suggested that we can
>>>> omit the first x30 pop here.
>>>> AFAICT, it seems fine and also safe for SCS. But I'm not sure if I'm
>>>> missing something with the kernel, could someone give some suggestions?
>>>> The previous discussion can be found here [1].
>>>> [1]
>>> As was pointed out in the discussion, binary patching is in fact a
>>> concern for the Linux kernel. E.g., Android uses generic binary
>>> builds, but we would like to be able to switch between pointer
>>> authentication and shadow call stack at boot time, rather than always
>>> support both, and take the SCS performance hit on systems that
>>> implement PAC as well.
>>> However, it seems more straight-forward to patch PACIASP and AUTIASP
>>> instructions into SCS push/pop instructions rather than the other way
>>> around, as we can force the use of these exact opcodes [in the NOP
>>> space]), as well as rely on existing unwind annotations to locate any
>>> such instruction in the binary.
>> Well, then I think I don't need to submit a kernel patch to
>> enable SCS for gcc :)
> Not entirely.
>> BTW:
>> Do we have a plan to submit patches of dynamic patch PAC into
>> the kernel recently?
> At the moment, there are just some ideas floating around. I did
> implement a proof of concept that uses unwind data, but it hit some
> issues with cfi_negate_ra_state being emitted imprecisely (GCC) or not
> at all (Clang) in some cases. Using objtool would be another
> possibility.
> So in summary, getting SCS support proper into GCC is definitely worth
> the effort.
Got it!

And thanks for the suggestion, Ard :)

Powered by blists - more mailing lists