Stack protector: leak of guard's address on stack

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

Hi,

For stack protector to be robust, at no point in time the guard against
which the canari is compared must be spilled to the stack. This is achieved
by having dedicated insn pattern for setting the canari and comparing it
against the guard which doesn't reflect at RTL what is happening. However
computing the address of the guard is done using standard movsi pattern and
can thus be spilled (see PR85434). I'm reaching out to the community for
ideas on how to avoid this.

Spilling is more likely in the context of PIC where the address is loaded
from the GOT and is thus not rematerialized. Likewise CSE make things worse
by reusing the address computed in the prologue to set the canari later in
the epilogue when performing the check, thereby being sensitive to peak
register pressure in the function. Aarch64 and I believe x86 backends don't
have the CSE issue for PIC because the GOT access is represented by an
outer UNSPEC whereas arm backend represent it by a MEM of an UNSPEC. I
think all targets are prone to issues in theory because the scheduler could
reorder the GOT access away from the guard/canari comparison which would
make a spill possible.

So far my feeling is that we would need new patterns that also cover the
guard's address computation but that would make such a pattern quite
complex to cover all the possible address.

Thoughts?

Best regards,

Thomas