LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: 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: Mon, 6 Oct 2008 15:01:01 -0700	[thread overview]
Message-ID: <20081006220101.GK10357@outflux.net> (raw)
In-Reply-To: <20081006192641.GI3180@one.firstfloor.org>

On Mon, Oct 06, 2008 at 09:26:41PM +0200, Andi Kleen wrote:
> > We're already using get_random* for stack, heap, and brk.  Also,
> > get_random* uses the nonblocking pool, so this is the same as if userspace
> > had tried to pull bytes out of /dev/urandom, which (as I understand it)
> 
> Yes exactly that's the problem. Think about it: do you really 
> need the same cryptographic strength for your mmap placement
> as you need for your SSL session keys?

Well, my ultimate intention was to put this into the stack protector
guard value, so I did want something as strong as the ASLR.

> Since so many systems have poor entropy input /dev/urandom has generally 
> replaced /dev/random for near all cryptographic software, so it's
> just the new black.

If I understand, you're suggesting that ASLR doesn't need to be strong,
and that there should be something besides get_random* used to produce
these values?  If that's true, that has nothing to do with the patch
I've suggested (i.e. we have an immediate need and I'm solving it using
the current available solutions.)  (Additionally, I think ASLR should be
as strong as possible.)

If instead, you're saying that the use of urandom has generally caused
a drain on entropy, and ASLR is suffering, then does it matter that a
few more bytes are used for the stack guard?  I'm just not clear what
direction you're trying to aim my patch.  :)

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.  Ulrich has a set of
requirements, and it sounds like there's a growing new set of requirements
from the kernel folks.  What's needed to sort this out?

-Kees

-- 
Kees Cook
Ubuntu Security Team

  reply	other threads:[~2008-10-06 22:02 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 [this message]
2008-10-06 23:19                   ` Andi Kleen
2008-10-06 23:29                     ` Kees Cook
2008-10-06 23:44                       ` Andi Kleen
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=20081006220101.GK10357@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=andi@firstfloor.org \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.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).