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: stack_protect_set/test

Hi Jakub,

> How much slower?
>         ear     %r12,%a0
> ...
>         mvc     116(4,%r15),20(%r12)
> against a memory load (assuming %r12 setup is necessary anyway, otherwise
> also the GOT setup sequence) and similar mvc.

On 64bit a tls canary test looks like:

        ear     %r1,%a0
        sllg    %r1,%r1,32
        ear     %r1,%a1
        clc     168(8,%r15),40(%r1)

The first 3 instructions can't be grouped because they have data dependencies.
And between the ear and the clc we have a full blown address generation
interlock counting with 4 cycles.

A GOT access would be:

	larl	%r12,GOT
	lg	%r1,offset(%r12)
	clc	168(8,%r15),0(%r1)

Setting up the GOT pointer would be done in the function prologue and as you
said is probably done anyway. Between the lg and the clc an address bypass
can be used needing 2 cycles.

So the tls variant costs us few more cycles. But this of course depends on how
many other instructions are available to be packed in between. 

> The TLS canary has at least two reasons, speed and avoiding COPY relocs.
> If __stack_chk_guard ends up living in program's .bss due to COPY
> relocation, it is far easier to overwrite it there by overflowing some
> .data section buffer preceeding it.

Ok. This improves security what I would rate over few cycles less per function.
I will discuss this with Ulrich and Martin (S/390 binutils) maybe they can come up
with a better way of doing this. Maybe there is a way putting the canary directly
into a got entry. But then we have the same problem addressing this value from
the executable - right?

> If TLS canary on s390{,x} is really much slower than __stack_chk_guard
> and we decide to use __stack_chk_guard there rather than the TLS canary,
> we need to do this ASAP (revert glibc changes for s390{,x}, so that
> __stack_chk_guard is exported on that arch).

I will hurry to come up with something.



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