Re: [PATCH] x86: Don't randomize stack unless current->personality permits it

[Al Boldi <a1426z@gawab.com>]

Paulo Marques wrote:
> Al Boldi wrote:
> >[...] > void fn() {
> >
> > 	long i = 9999999;
> > 	double x,y;
> >
> > 	elapsed(1);
> > 	while (i--) fn2(&x,&y);
> > 	printf("%4lu ",elapsed(0));
> > }
>
> You are not initializing x and y and with -Os at least my gcc really
> uses floating point load/store operations to handle that code.

Thanks for pointing that out.

I was really waiting for someone to critique this, but keep in mind this code 
tries to surface a performance problem, and any modification changes the 
semantics of the compiled code, which then may yield different results.

> Maybe the coprocessor has a hard time normalizing certain garbage on the
> stack, but without/with randomization the data comes from other
> addresses and you're just lucky with the contents.

Good point, but this random garbage makes the test even more realistic, as 
this code would thus cover more variations without actually coding for it.

> Does this also happens if you add a "x=0, y=0;" line to that function?

with arch_stack_align using 0xf
gcc -Os tstExec.c
randomization on
causes 2x blips/hits
randomization off
causes no blips/hits
mv a.out tstExec
causes continuous 2x slowdown
sh -c ./tstExec
causes slowdown to disappear (can somebody explain this weirdness?)

with arch_stack_align using 0x7f
all weirdness is gone
gcc -O3 tstExec.c
randomization on
causes some minor blips/hits
randomization off
causes even less blips/hits

Going one step further,
with #define arch_stack_align(x) (x)
all blips/hits/weirdness are gone

Which means that either arch_stack_align isn't necessary at all, or 
randomization isn't working as intended.

Can somebody prove me wrong here?

Thanks!

--
Al