This is the mail archive of the
mailing list for the GCC project.
Re: Stack protector: leak of guard's address on stack
- From: Thomas Preudhomme <thomas dot preudhomme at linaro dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 27 Apr 2018 14:31:25 +0100
- 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>
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.
On 27 April 2018 at 13:22, Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Fri, Apr 27, 2018 at 01:17:50PM +0100, Thomas Preudhomme wrote:
> > It's not the canari which is spilled in this case, but the address to the
> > canari. Which means an attacker could make it point to something else
> > the real canari.
> When the canary is in TLS area, it is usually small constant away from some
> base register (or segment register) and there is no possibility of having
> that spilled, the addition is done always in the instruction performing
> memory read of the canary.