Re: Stack protector: leak of guard's address on stack

[Thomas Preudhomme <thomas dot preudhomme at linaro dot org>]

Yes absolutely, CSE needs to be avoided. I made memory access volatile
because the change was easier to do. Also on Arm Thumb-1 computing the
guard's address itself takes several loads so had to modify some more
patterns. Anyway, regardless of the proper fix, do you have any objection
to raising a CVE for that issue?

Best regards,

Thomas

On 27 April 2018 at 14:38, Jakub Jelinek <jakub@redhat.com> wrote:

> On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote:
> > On x86 yes, it's actually done in the same instruction that's doing the
> > comparison if I'm not mistaken. That is not the case for arm and aarch64
> > though where loading the canari is done separately from the comparison
> and
> > does not involve an offset. Computing the address from which to do the
> load
> > is yet again done in a separate instruction. Since these are extra
> > instructions and the address of the canari does not change between the
> > prologue and epilogue, CSE is done on the address (only on arm backend
> > though) and due to register pressure the address is spilled on the stack.
>
> So just add some UNSPEC around to prevent the CSE (with different number on
> the prologue and epilogue load, so that the two are considered
> different).  Even
> when it isn't spilled in the current function, it might be saved and
> restored in
> function's it calls and again, an attacker could modify it there.
>
>         Jakub
>