LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Kees Cook <kees.cook@canonical.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, Jakub Jelinek <jakub@redhat.com>,
	Ulrich Drepper <drepper@redhat.com>,
	libc-alpha@sourceware.org
Subject: Re: [PATCH] ELF: implement AT_RANDOM for future glibc use
Date: Tue, 7 Oct 2008 01:44:44 +0200	[thread overview]
Message-ID: <20081006234444.GA20740@one.firstfloor.org> (raw)
In-Reply-To: <20081006232936.GR10357@outflux.net>

On Mon, Oct 06, 2008 at 04:29:36PM -0700, Kees Cook wrote:
> > > I'd really love to see this solved.  My goal is to get a mainline glibc
> > > patch for a low-cost randomized stack guard value.
> > 
> > Your current implementation is high cost.
> >...
> > random32() is not a cryptographically strong RNG. I suspect it would
> > be pretty easy to reverse engineer its seed given some state. It hasn't
> > been designed to be protected against that.
> 
> It's being used for randomness in the networking code, so it's at least
> mildly random "enough".

Only for applications there which are not considered security sensitive.
I think. A general review of all the rngs in the kernel would be 
probably a good idea. 

Note that there are also several degrees of random
requirements in the networking code.
e.g. IPsec clearly needs stronger randomness than pktgen.

A lot of users are somewhere inbetween. e.g. I suspect the regular
routing cache rehashing would also be a excellent client of a 
a new medium quality rng facility.

> 
> > IMHO it needs a new class of random numbers in the kernel that use
> > some cryptographically strong RNG (there are a couple of candidates
> > like yarrow) which is very rarely seeded
> > from the entropy pool[1] and use that for these applications.
> > A couple of other users in the kernel would benefit that too,
> > most users of get_random_bytes() probably should be reviewed
> > for their true requirements.
> 
> Sure, but this is a larger (and pre-existing) problem.

Yes it is, but since you propose to extend the problematic 
usage much further (and also eating incredible amounts of entropy
on many workloads) you end up with the task of solving 
this problem first, sorry.

> 
> > Ideally expose it to userland too so that dumb users like
> > tmpfile can use it too. 
> 
> Would you propose that it get hooked to /dev/urandom?

It would need to be a new device.

The problem is that since noone in their right mind really still
uses /dev/random (except perhaps for gpg secret keygen) a lot
of real cryptographic applications also use /dev/urandom. And silently
changing the semantics under those wouldn't be nice.

The abusers like tmpfile etc. would just need to be fixed to 
use a different interface.

-Andi

-- 
ak@linux.intel.com

  reply	other threads:[~2008-10-06 23:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081001201116.GD12527@outflux.net>
     [not found] ` <48E3EFD6.2010704@redhat.com>
     [not found]   ` <20081001215657.GH12527@outflux.net>
     [not found]     ` <20081001220948.GC32107@sunsite.ms.mff.cuni.cz>
     [not found]       ` <20081001222706.68E7E1544B4@magilla.localdomain>
2008-10-03  0:16         ` Kees Cook
2008-10-03  0:43           ` Jakub Jelinek
2008-10-03  5:25             ` Kees Cook
2008-10-03  5:29             ` Kees Cook
2008-10-03  5:57               ` Arjan van de Ven
2008-10-03  6:25                 ` Ulrich Drepper
2008-10-03 14:50                   ` [PATCH] ELF: implement AT_RANDOM for glibc PRNG seeding Kees Cook
2008-10-03 14:56                     ` Ulrich Drepper
2008-10-03 14:57                     ` Jakub Jelinek
2008-10-03 17:33                       ` Kees Cook
2008-10-03 17:41                         ` Ulrich Drepper
2008-10-03 17:59                           ` [PATCH v5] " Kees Cook
2008-10-18  5:42                             ` Ulrich Drepper
2008-10-21 20:01                             ` Andrew Morton
2008-10-21 20:22                               ` Ulrich Drepper
2008-10-27  5:46                                 ` Andrew Morton
2008-10-03  0:52           ` [PATCH] ELF: implement AT_RANDOM for future glibc use Roland McGrath
2008-10-03  5:15             ` Kees Cook
2008-10-03 20:22               ` Roland McGrath
2008-10-06  6:00           ` Andi Kleen
2008-10-06 17:50             ` Kees Cook
2008-10-06 18:25               ` David Wagner
2008-10-06 20:23                 ` Andi Kleen
2008-10-06 22:16                   ` David Wagner
2008-10-06 19:26               ` Andi Kleen
2008-10-06 22:01                 ` Kees Cook
2008-10-06 23:19                   ` Andi Kleen
2008-10-06 23:29                     ` Kees Cook
2008-10-06 23:44                       ` Andi Kleen [this message]
2008-10-06 22:07                 ` Kees Cook
2008-10-06 23:28                   ` Andi Kleen
2008-10-06 23:58                   ` Roland McGrath
2008-10-07  0:08                     ` Ulrich Drepper
2008-10-07  0:31                     ` Kees Cook
2008-10-07  0:57                       ` Ulrich Drepper
2008-10-07  1:44                         ` Kees Cook
2008-10-07  1:51                           ` Ulrich Drepper

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=20081006234444.GA20740@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.com \
    --cc=kees.cook@canonical.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --subject='Re: [PATCH] ELF: implement AT_RANDOM for future glibc use' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).