https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilco at gcc dot gnu.org
--- Comment #2 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Jim Wilson from comment #0)
> Given a simple testcase
> extern int sub (int);
>
> int
> main (void)
> {
> sub (10);
> return 0;
> }
> commpiling with -O -S -fstack-protector-all -mstack-protector-guard=global
> in the epilogue for the canary check I see
> ldr x1, [sp, 40]
> ldr x0, [x19, #:lo12:__stack_chk_guard]
> eor x0, x1, x0
> cbnz x0, .L4
> Both x0 and x1 have the stack protector canary loaded into them, and the eor
> clobbers x0, but x1 is left alone. This means the value of the canary is
> leaking from the epilogue. The canary value is never supposed to survive in
> a register outside the stack protector patterns.
>
> A powerpc64-linux toolchain build with the same testcase and options
> generates
> lwz 9,28(1)
> lwz 10,0(31)
> xor. 9,9,10
> li 10,0
> bne- 0,.L4
> and note that it clears the second register after the xor to prevent the
> canary leak. The aarch64 stack_protect_test pattern should do the same
> thing.
The canary value is not a secret. What would the purpose of clearing the
register be given the stack slot containing the canary is not cleared as well?
And register could potentially contain the address of the canary or that of a
global nearby, making reading the canary value really easy.
