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-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jul 2006 20:21:09 -0400
From:	Chuck Ebbert <76306.1226@...puserve.com>
To:	Al Boldi <a1426z@...ab.com>
Cc:	Paulo Marques <pmarques@...popie.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Frank van Maarseveen <frankvm@...nkvm.com>
Subject: Re: [PATCH] x86: Don't randomize stack unless
  current->personality permits it

In-Reply-To: <200607241857.46594.a1426z@...ab.com>

On Mon, 24 Jul 2006 18:57:46 +0300, Al Boldi wrote:
>
> > With your changes on:
> >
> > stock kernel, randomize_va_space=0, gcc.322 -Os tstExec.c,
> > while :; do ./a.out; done
> > &x = 0xbffff874, &y = 0xbffff86c   28   28
> > &x = 0xbffff874, &y = 0xbffff86c   27   27  
> > &x = 0xbffff874, &y = 0xbffff86c   27   27
> > &x = 0xbffff874, &y = 0xbffff86c   28   27
> > &x = 0xbffff874, &y = 0xbffff86c   27   30
> > &x = 0xbffff874, &y = 0xbffff86c   27   29
> >
> > stock kernel, randomize_va_space=1, gcc.322 -Os tstExec.c,
> > while :; do ./a.out; done
> > &x = 0xbfe2e614, &y = 0xbfe2e60c   29   28
> > &x = 0xbfd6a104, &y = 0xbfd6a0fc   55   56  
> > &x = 0xbf91d454, &y = 0xbf91d44c   27   27
> > &x = 0xbf941e84, &y = 0xbf941e7c   55   56
> > &x = 0xbfa75834, &y = 0xbfa7582c   28   27
> > &x = 0xbfb58634, &y = 0xbfb5862c   27   30
>
> After closer inspection, it looks like addresses ending with 3c,7c,bc,fc 
> cause a slowdown on P4, while addresses ending with 1c,3c,5c,7c,9c,bc,dc,fc 
> cause a slowdown on P2.
>

Those addresses cause 'y' to span a cacheline (P4 = 64 bytes, P2 = 32.)
Even when the kernel aligns to 128 bytes this could happen depending
on how deeply you nest functions.

> Any easy way to instruct the kernel to skip those addresses?

First, I think you need to define locals in order of decreasing size.
IOW 'x' and 'y' need to be first inside fn(), but that may not work
when things get inlined.  So using the '-malign-double' GCC option,
or forcing alignment with '__attribute__ ((aligned(8)))' for each variable
might be better.

Then you have to make sure the stack is aligned. See
'-mpreferred-stack-boundary'.

I still think the kernel should be aligning the stack to 128 bytes anyway.

-- 
Chuck

-
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/