per-task stack canaries for arm64

Ard Biesheuvel ard.biesheuvel at linaro.org
Mon Jan 22 04:42:10 PST 2018


On 22 January 2018 at 12:26, Kees Cook <keescook at chromium.org> wrote:
> On Mon, Jan 22, 2018 at 9:59 PM, Ard Biesheuvel
> <ard.biesheuvel at linaro.org> wrote:
>> OK, so I have done a bit of homework, and I think this shouldn't be
>> too difficult after all.
>>
>> I realized that we don't really need per-CPU references to
>> __stack_chk_guard, given that we already keep the task struct pointer
>> in sp_el0. This means we should be able to do
>>
>> mrs   x0, sp_el0
>> movz  x1, :abs_g0:__stack_chk_guard_tsk_offset
>> add   x0, x0, x1
>> ldr   x2, [x0]
>>
>> where __stack_chk_guard_tsk_offset is exposed via an ELF symbol.
>> (Analogous to x86, this could be implemented at the GCC level using
>> arbitrary sysreg and symbol names to remain flexible)
>>
>> So my next question (mainly to Ramana): would it be possible to emit
>> the mrs/movz/add sequence above from targetm.stack_protect_guard() in
>> a way that will allow expand_normal() to expand it in a useful manner
>> (e.g., as an INDIRECT_REF that can be matched by the memory_operand in
>> Aarch64's stack_protect_set)? If that is the case, we could implement
>> this in a GCC plugin in the kernel rather than relying on upstream GCC
>> changes (and having to commit to this ABI long term)
>
> Though this would ultimately be implemented in core GCC, yes? (I don't
> want to have GCC plugins be a dependency for stack protector...)
>

Oh absolutely. But being able to expose this more widely early on,
while GCC 9 is still under development, would help prevent cockups
where we end up with a flawed ABI and it's too late to do something
about it.



More information about the linux-arm-kernel mailing list