Re: [RFC] Per-architecture randomization

[Arjan van de Ven]

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.

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