Hello,
On Mon, Jun 07, 2010 at 06:50:11PM +0100, Andy Bennett wrote:
Thanks for this Andy!
I've been running
watch -n 0.25 cat /proc/sys/kernel/random/entropy_avail
...as recommended buy Hugo in the comments and my VPS fills up with
entropy very quickly.
Er. :) I don't think that was a recommendation as such. His point
was that creating a process uses up some entropy, so by creating
them quite fast (every 0.25s) you should see the available entropy
drop quite quickly when in theory all you are doing is reading how
much you have.
In my case I had to do it every 0.1 seconds to really force the
entropy to be depleted but it depends how much your kernel is
managing to gather and how much it's having to use for other things.
When I first started looking it was at 185 but now it
seems stuck at
3585. If I do things over imaps it will drop briefly and then refill to a
stable 3585 over the next few seconds.
That's pretty good and is not unusual. Several of my own VMs show no
real problems:
http://tools.bitfolk.com/cacti/graph_1855.html
http://tools.bitfolk.com/cacti/graph_1896.html
http://tools.bitfolk.com/cacti/graph_1902.html
so I won't be hooking these up to the entropy service.
It clearly depends a lot on what the VM is doing, both to generate
and consume entropy.
On my desktop machine, a Core 2 Duo with an Intel TPM
and apparently a
load of crypto gubbins, my entropy sits around 140 the entire time and
struggles to get above 200.
I'd like to know of a way to see where it's getting entropy from and
what is requesting it, so it would be clearer if it's a supply
problem or a demand problem or a bit of both.
In the past I've seen smtps mail submissions stall
for arbitrary lengths
of time and very occasionally even timeout completely. I've always put
this down to a lack of entropy: now I wonder which end was lacking.
If you install egd then you can make it execute arbitrary commands
to generate a pool of entropy which it will serve on a Unix socket.
If you install ekeyd-egd-linux then you can have it read that socket
and top up your kernel's entropy from it. None of that requires
hardware crypto or an Entropy Key or anything. You'd have to be
careful that the random stuff you gave it was secure, but maybe it
would be good enough just for testing purposes to see if things go
faster when there's more entropy available.
Or you could just symlink /dev/random to /dev/urandom - that's
probably a lot quicker to test with :)
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"I remember the first time I made love. Perhaps it was not love exactly but I
made it and it still works." -- The League Against Tedium