mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: John Richard Moser <nigelenki@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Per-architecture randomization
Date: Sun, 04 Jun 2006 11:06:08 +0200	[thread overview]
Message-ID: <1149411968.3109.79.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <44825E42.5090902@comcast.net>

On Sun, 2006-06-04 at 00:14 -0400, John Richard Moser wrote:
> Pavel Machek recommended per-architecture randomization defaults when I
> poked a (very hackish) patch up here.  As follow-up, I have taken out
> the command line parameter code and used the infrastructure I wrote to
> implement per-architecture randomization settings.
> 
> Three #defines are needed per architecture, preferably in
> include/asm-ARCH/processor.h or equivalent.  These defines are as follows:
> 
>  STACK_ALIGN -- Alignment of the stack, typically 16 (bytes).
>     If not defined, stack randomization is carried out to page
>     granularity
>  ARCH_RANDOM_STACK_BITS -- Bits of entropy to apply to the stack.
>     If not defined, stack randomization is disabled by defining this
>     as 0.
>  ARCH_RANDOM_MMAP_BITS -- Bits of entropy to apply to the mmap() base.
>     If not defined, mmap() randomization is disabled by defining this
>     as 0.


eh....

I think you missed a few things..
like
1) This is per architecture already for the most part!
   arch_align_stack() is obvious per architecture already
   the mmap randomisation also happens in arch/<foo>/mm
   and this is per arch by definition as well
2) you missed that the mmap randomization is *ON TOP OF*
   the stack randomization. So while you say "1Mb" in your
   doc in practice it is 8Mb

Also your patch is still full of XXX's and "other noise"... 
Also you probably should explain what the advantage is over the existing
per architecture approach. Just stating "it's per architecture" (as you
suggest) doesn't cut it since it is per architecture already for the
most part.

If all you want to do is turn 
-       if (current->flags & PF_RANDOMIZE)
-               random_variable = get_random_int() % (8*1024*1024);

that 8 into a per architecture thing.. then your patch is awefully big
and complex to just achieve that.


  reply	other threads:[~2006-06-04  9:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-04  4:14 John Richard Moser
2006-06-04  9:06 ` Arjan van de Ven [this message]
2006-06-04 16:14   ` John Richard Moser
2006-06-04 17:15     ` Arjan van de Ven
2006-06-04 18:35       ` John Richard Moser
2006-06-04 18:56         ` Arjan van de Ven
2006-06-04 19:10           ` John Richard Moser
2006-06-04 18:44 ` John Richard Moser

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=1149411968.3109.79.camel@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigelenki@comcast.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®