Re: [IPCop-devel] Failure to build IPCop v1.4 on kernel version> 2.6.11

[Gilles E. <g....@fr...>]

----- Original Message ----- 
From: "Achim Weber" <dot...@gm...>
To: <ipc...@li...>
Sent: Wednesday, October 26, 2005 6:45 AM
Subject: Re: [IPCop-devel] Failure to build IPCop v1.4 on kernel version>
2.6.11


> > Am I the only one wich is experimenting a problem during openswan
> > compilation with a 2.6.12 or 2.6.13 kernel?
> >
> > I have tested on 2 differents machines and distribution (RH7.3 and
Gentoo).
> > It work under a 2.4 kernel until 2.6.11.7. Then it fail with 2.6.12.6
and
> > 2.6.13.4.
> >
> > openswan-1.10rc2 hang during /dev/random access like this :
> > getting 137 random bytes from /dev/random...
> > looking for a prime starting there (can take a while)...
> > found it after 9 tries.
> > getting 137 random bytes from /dev/random...
> >
> > And nothing more happen until it is interrupted.
> >
> > The problem may be related to my kernel .config but before investigating
in
> > detail, I would be happy to have feedback from others.
> >
> > Gilles
>
> Hi Gilles,
>
> no problems here. I had a fresh 1.4.10 ISO this morning.
> Buildsystem is Debian Sarge with (custom) kernel 2.6.12 :-)
> I made a cvs update, make.sh prefetch/clean before building.
>
> Achim
>
I know now the cause of the problem.
It is not related to a kernel setting but to a change in 2.6.12 how entropy
pool is populated for dev/random usage.
entropy_avail size depend how you work on the machine, keyboard or disk
usage fill entropy pool.

Contrary to what is commonly written, network traffic will not always
contribute to fill entropy pool. It may depend wich hardware you use.
To verify this point, you just have to make
grep -B 1 -r RANDOM drivers/net/*
and you will see that just a few drivers use SA_SAMPLE_RANDOM on IRQ call.
(I just look on 2.4.31)
This is related to the facts that network traffic may be view from the
outside, so one may guess what is inside /dev/random.
My understanding is that it would be very difficult to guess because no disk
access feeding the pool need to be done during the time needed to find the
right content of the entropy pool.

The machine I use to compile is mainly remotly exploited, do not have many
cron job, have 512Mb memory installed.
Probably due to ccache usage and to the size of memory installed wich let
much memory available for disk cache, disk usage may not be enought sometime
to feed the entropy pool.

On 2.6.11, during V1.4 or V1.5 compilation, entropy_avail average size is in
the range 1296..4096, on most recent kernel (2.6.12.6/2.6.13.3/2.6.14), it
is between 128 and 191 everytime but during openswan-1.10 compilation.
openswan-1.10rc2 compilation inside the chroot with kernel 2.4.31 sources
consume more entropy than available during some /dev/random access to create
key (this is not the case of openswan-2.2 wit a 2.6 kernel sources)
entropy_avail size drop to near 0 and /dev/random may wait indefinetly for
the pool been enough populated.

For testing, I use entropy_avail.sh (url in the LFS hint)
http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt
It is basicaly a loop every second wich read the pool size and write a log
to the disk.
Writing the log to the disk had the side effect to add a few entropy related
to disk usage.
It let openswan-1.10rc2 compile on 2.6.12 and later with a side effect that
it take more time (20 mn against probably 5mn on 2.6.11) due to numerous
waits of the pool been enought populated.

This let some questions open for futur IPCop version.
A machine used with a flash disk have far less disk access than my
compilation machine.
Does a write on the ramdisk feed the pool?
Will default entropy pool size big enough if multiple VPN are started at the
same time like when ISP disconnect and reconnect one machine with a
different IP?
What are openswan-2.x needs related to entropy?
Should we support hardware random generators include in the kernel?

Gilles