This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] S/390: Use FRAME_GROWS_DOWNWARD - take 2

Jakub Jelinek <> wrote on 29.06.2005 10:56:20:

> On Wed, Jun 29, 2005 at 10:50:27AM +0200, Andreas Krebbel wrote:
> > this is the patch adapted to the recent FRAME_GROWS_DOWNWARD changes
> > done by Jakub.
> Great (I was planning on looking at this today (s390* and ia64)).
> Do you plan to also add the stack_protect_{set,test} patterns?

As far as I've understood these patterns they should not be necessary
on S/390. We have a mem/mem mov as well as a mem/mem compare so
there should be no risk exposing the canary value in a register.

Actually I must admit that it is not clear to me how an attacker
could make use of this value if it resides in a register. When the
return address pointer on stack gets overwritten (and hopefully the canary
value too) there is no code executed which could be introduced by the
so what code can draw advantage of the canary value left in a register? And
if the attacker is able to read the value from a reg what should prevent
him from taking
the canary value direcly from the stack location whereto it was saved by

Possibly it may be necessary to provide a stack_protect_test pattern also
for S/390 because
combine does not dare to merge the two memory loads (from stack_chk_guard
and from the stack
itself) with the compare instruction which would finally result in a single
clc. The problem
for combine seem to be that the memory locations are marked volatile.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]