Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes

From: Ingo Molnar <mingo@elte.hu>
To: Matt Mackall <mpm@selenic.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Arjan van de Ven <arjan@infradead.org>, Jake Edge <jake@lwn.net>,
	security@kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	Eric Paris <eparis@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Roland McGrath <roland@redhat.com>,
	mingo@redhat.com, Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <greg@kroah.com>, Dave Jones <davej@redhat.com>
Subject: Re: [Security] [PATCH] proc: avoid information leaks to non-privileged processes
Date: Thu, 7 May 2009 20:21:04 +0200	[thread overview]
Message-ID: <20090507182104.GA30659@elte.hu> (raw)
In-Reply-To: <20090507181434.GL31071@waste.org>

* Matt Mackall <mpm@selenic.com> wrote:

> >  aldebaran:~/l> ./lat_proc fork
> >  Process fork+exit: 61.7865 microseconds
> 
> Uh, what? There's no exec() involved in fork+exit, so hopefully 
> ASLR doesn't decide to make an appearance.

We use it to seed the per task stackprotector secret. Look for 
get_random_int() in kernel/fork.c.

(
  Now, if get_random_int() slows down we could certainly water that 
  down and have a system-wide secret and some easy and fast 
  long-cycle permutation code to make it not so easy to figure out 
  the core secret from a kernel crash signature.

  [ Alas, that might be worth doing in any case - to not have 
    get_random_int() in the clone() / pthread_create() fastpath. ]

  We really need a design decision there - if get_random_int() is 
  supposed to be a mathematically safe hash, ignoring the physics of 
  the world, then we need a separate get_random_int_fast() API or 
  so. All current users of get_random_int() will evaporate as well. 
)

	Ingo