public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: John Richard Moser <nigelenki@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization
Date: Sat, 20 May 2006 13:13:43 -0400	[thread overview]
Message-ID: <446F4E47.6000304@comcast.net> (raw)
In-Reply-To: <446E6A3B.8060100@comcast.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



John Richard Moser wrote:
[...]

I've got a new working version over here, it's currently building over
on my laptop for test.  It looks a lot cleaner now, still a little messy
in some places for my tastes... a few functions I declare 2-5 more
variables in!

I also haven't fixed the arch_align_stack() in
arch/um/kernel/process_kern.c to match... and I'm getting tired of
maintaining 3 copies of what started as the same exact code and is
currently STILL the same exact code, just 15 times bigger!  Does anyone
have a good place to stick arch_align_stack()?  It can stay wrapped in
#ifndef like in arch/um/kernel/process_kern.c, because this method
should work for all architectures that don't '#define
arch_align_stack(x) (x)'.

>  - stack_random_bits is used to calculate how to shift the stack around.
>  If it's >8, then stack_random_bits - 8 is used to shift the page
> alignment of the stack.  if it's >0, then its value (or 8 if it's >8) is
> used to calculate the interval on which to align the randomly-placed
> stack pointer within the first page.  If it's 0, no randomization happens.
> 

At this point, it actually calculates how many bits go into sub-page
randomization with long_log2(PAGE_SIZE / 16) instead of just assuming 8.

[...]

> 
> 
> There's a few other things I want to get done, but I'll worry about
> those later.  They are:
> 
>  - Take care of the FIXME in that __init code in fs/exec.c to use
> architecture-specific #defines for the maximum values of these
> parameters, probably in asm-* somewhere.

Fixed.  We no longer care.  In arch/i386/mm/mmap.c; fs/binfmt_elf.c;
arch/i386/kernel/process.c; and arch/x86-64/kernel/process.c, we
calculate the maximum amount of entropy based on how many bits can be
done in (TASK_SIZE / 6).  This as an intended side effect also means
that IA-32 emulation on x86-64 results in proper reduction of entropy
(down to 256MiB ranges for stack and mmap())

>  - Add /proc controls to tweak system-wide randomization on new processes.

Arjan van de Ven raised a good point:

"(if we would put a knob on everything that is a value in the kernel
we'd have five gazilion knobs)"

We don't need /proc control for this; SELinux control should be enough.
 The kernel command line parameter could be removed as soon as SELinux
policy could adjust these settings; the default values when no
parameters are given are the settings the kernel uses now.

>  - Add LSM/SELinux hooks to let policy tweak randomization per-binary,
> so high-order randomization can be used except for with i.e. Oracle
> (which tries to mmap() 2GiB in at once and can thus die from VMA
> fragmentation).

Don't have these yet; although I put a couple /*XXX: */ comments in
where I feel these should go.

>  - Figure out exactly what affects what architecture, and which
> architectures react differently in terms of randomization; correct the
> calculations in these cases, i.e. if the stack can't be randomized
> within the page, stack_random_bits should apply to page randomization.
>  - Try getting randomization working in other architectures where it's
> not right now.  I don't see anything obvious to me that shows i.e. Sparc
> having randomization.. but I'm not much of a kernel hacker....


Really, really would be nice.... a little help here?  :)

>  - Get somebody to get some sort of heap randomization in here, and do
> the same deal.  Doesn't Fedora do heap randomization?

Anyone have an answer for this one?  I can't get Fedora Core 5 working
in Qemu (install DVD hangs as soon as it sees the hard drive) and I
can't find an FC5 LiveCD...

[...]

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRG9ORQs1xW0HCTEFAQIvlA/+P8bLXdW2yqYewVgDJzYjsSsy/c0Fgzy+
2SY5sJjMMbS08+gfSqSbIRtAZf2N7iJLOxWP1JpwWoZxVj+QMSDWEEmt4552/bi1
00yMwQ6aFmF3nkCXwpj2mLiR8P8KFQJp4U0LPaOOlEt8/6OJgC+wbR2B0nm4rxFg
RRgaNeeenB95smfis54cu64EFyTwxlsNdW7H47Zgu7SBnNsmSAf2iZ3b5Gf4zTaA
PhH8syEMxH2SGwwkEumylDdmIUBw/5yzSIwmevp7wrG8SNHuaCE9LI1lR6bSubNu
84Wmiq4hv+kIYdm+9hdnOcC/27THKHCFq9JawMDnvcZMYQmvJDMiO++aHfRufhl7
wm0bAMfgObDVy+WJOyCfryGxb6DZv9xvktXfTj7xEtsRm8DWbGdbiivoOm6Kk7tc
PuEJJqOy2gHGPfM18RVYAfdspkYcc55VAJhwIMEux+ATLOf4Y30kaWi3VLP8pXLo
6m0pJFeaLKS+fAwXnc3PYWbzpCmrZAr8ZFamhfLlEnA/8i8siNQCw98WhEXIxUkI
wtUFnHFPhtC2QkDn/fNnbYpSMR+SQOOOBK7+u8U2WrCZEuaFif1Pq7XULGWSfHPq
RW3s/jzEjLc+ngvGEqrADIglde/ced4CrEhRHH4RQQrjn5DhseXh8euQ+3qG69wU
EQU3Fw0XQ/Y=
=yYp4
-----END PGP SIGNATURE-----

      parent reply	other threads:[~2006-05-20 17:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-20  1:00 [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization John Richard Moser
2006-05-20  3:36 ` John Richard Moser
2006-05-20  5:23 ` John Richard Moser
2006-05-20 13:47 ` Arjan van de Ven
2006-05-20 15:23   ` John Richard Moser
2006-05-22  1:06     ` Pavel Machek
2006-05-22  2:46       ` John Richard Moser
2006-05-22  8:33         ` Pavel Machek
2006-05-22 16:31           ` John Richard Moser
2006-05-22 17:00             ` Pavel Machek
2006-05-22 17:54               ` John Richard Moser
2006-05-22 18:40                 ` Pavel Machek
2006-05-22 19:02                   ` John Richard Moser
2006-05-22 19:12                     ` Pavel Machek
2006-05-22 19:27                       ` John Richard Moser
2006-05-22 19:41                         ` Pavel Machek
2006-05-22 20:05                           ` John Richard Moser
2006-05-23  1:05             ` Arjan van de Ven
2006-05-23  1:34               ` John Richard Moser
2006-05-20 17:13 ` John Richard Moser [this message]

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=446F4E47.6000304@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox