From: Chuck Ebbert <76306.1226@compuserve.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@osdl.org>, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH for 2.6.18rc2] [1/7] i386/x86-64: Don't randomize stack top when...
Date: Tue, 25 Jul 2006 05:06:07 -0400 [thread overview]
Message-ID: <200607250508_MC3-1-C604-C1C9@compuserve.com> (raw)
In-Reply-To: <1153815124.8932.15.camel@laptopd505.fenrus.org>
On Tue, 25 Jul 2006 10:12:04 +0200, Arjan van de Ven wrote:
> > > unsigned long arch_align_stack(unsigned long sp)
> > > {
> > > - if (randomize_va_space)
> > > + if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
> > > sp -= get_random_int() % 8192;
> > > return sp & ~0xf;
> > > }
> >
> > I think this needs to be done always, at least on P4. It really isn't
> > 'randomization' at the same high level as the rest -- more like a small
> > adjustment. And the offset should be a multiple of 128 and < 7K (not
> > 8K.) Something like this:
>
> the 8K was what Intel proposed for 2.4 quite a while ago and has been in
> use in linux for years and years... Can you explain why you are saying
> 7Kb? throwing away that 1Kb of cache associativity is unfortunate and
> shouldn't be done unless there's a good reason, so I'm quite interested
> in finding out your reason ;)
Well that's what the Intel IA-32 optimization manual says:
To establish a suitable stack offset for two instances of the same
application running on two logical processors in the same physical
processor package, the stack pointer can be adjusted in the entry
function of the application using the technique shown in Example 7-5.
Example 7-5 Adding a Pseudo-random Offset to the Stack Pointer
in the Entry Function
void main()
{
char * pPrivate = NULL;
long myOffset = GetMod7Krandom128X()
// A pseudo-random number that is a multiple
// of 128 and less than 7K.
// Use runtime library routine to reposition.
_alloca(myOffset); // The stack pointer.
}
IA-32 Intel Architecture Optimization Reference Manual, Ch. 7
June 2005
--
Chuck
next reply other threads:[~2006-07-25 9:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 9:06 Chuck Ebbert [this message]
2006-07-25 11:38 ` [PATCH for 2.6.18rc2] [1/7] i386/x86-64: Don't randomize stack top when Andi Kleen
2006-07-25 11:48 ` Arjan van de Ven
-- strict thread matches above, loose matches on Subject: below --
2006-07-25 7:46 Chuck Ebbert
2006-07-25 8:12 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200607250508_MC3-1-C604-C1C9@compuserve.com \
--to=76306.1226@compuserve.com \
--cc=ak@suse.de \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.