Messages in this thread | | | Date | Sun, 26 Oct 2008 22:46:59 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v5] ELF: implement AT_RANDOM for glibc PRNG seeding |
| |
On Tue, 21 Oct 2008 13:22:18 -0700 Ulrich Drepper <drepper@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Morton wrote: > > I read the above changeloglet and read the above-linked page and it's > > still 87% unclear to me what this feature does. Something to do with > > stack randomisation, apparently. I suppose I could go do further > > hunting, but from the quality-of-changelog POV I don't think I should > > need to do so. > > Not stack randomization. glibc needs right after startup a bit of > random data for internal protections (stack canary etc). What is now in > upstream glibc is that we always unconditionally open /dev/urandom, read > some data, and use it. For every process startup. That's slow. > > In addition Andi mentioned that this use of /dev/urandom might be > problematic. I let him explain this. > > The solution is to provide a limited amount of random data to the > starting process in the aux vector. I suggested 16 bytes and this is > what the patch implements. If we need only 16 bytes or less we use the > data directly. If we need more we'll use the 16 bytes to see a PRNG. > This avoids the costly /dev/urandom use and it allows the kernel to use > the most adequate source of random data for this purpose. It might not > be the same pool as that for /dev/urandom. >
Thanks.
> > It's unclear to me that the random-number issue got sorted out? > > I think the last patch used the normal function to get 16 random bytes, > equivalent to the data used for stack randomization etc. > > If Andi has concrete proposals for a revamp of the use of entropy in the > kernel this can be easily done as an add-on. This patch doesn't make > the situation worse, it doesn't deplete entropy more than it happens now. >
True.
As long as glibc doesn't do the /dev/urandom read when the kenrel has already done that. I assume that it will do so, until AT_RANDOM-aware glibc has propagated out?
| |