This is the mail archive of the
mailing list for the GCC project.
Re: Stack protector: leak of guard's address on stack
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Preudhomme <thomas dot preudhomme at linaro dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 27 Apr 2018 15:38:45 +0200
- Subject: Re: Stack protector: leak of guard's address on stack
- References: <CAKnkMGsEPiRoKBHEJVrnHbGLNx-7gZk0Kt7uqJRMZgQD1Uh=Wg@mail.gmail.com> <20180427121601.GT8577@tucnak> <CAKnkMGsgfApCWmLfsGfFrHejR4xLotx4B1wUX8XAAo=ceh+EoQ@mail.gmail.com> <20180427122204.GU8577@tucnak> <CAKnkMGtZyZojdWkFH91TS9Hy2knttesSfcFNRdakOSjb3r03AQ@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.