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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200607180821.45346.a1426z@gawab.com>
Date:	Tue, 18 Jul 2006 08:21:45 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Paulo Marques <pmarques@...popie.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Frank van Maarseveen <frankvm@...nkvm.com>,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...e.de>
Subject: Re: [PATCH] x86: Don't randomize stack unless current->personality permits it

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/