On Mon, 21 Feb 2005, Peder Chr. Nørgaard wrote: > durned thing. A closer investigation showed that the installation hangs in > program "ipsec rsasigkey" reading /dev/random. > > Now I have studied the driver/char/random.c for a while. It looks as if it > works allright, also in user-mode-linux, it just needs to get a unholy lot of > what it calls "entropy" to provide the "ipsec rsasigkey" installation with > the necessary amount of bits for it to build the keys.
Someone suggested creating /dev/random with the minor number of /dev/urandom. The latter does not block even when it runs out of entropy. But if the crypto keys are going to withstand an attack, they need the entropy. Could you create the keys in advance on a real machine? FreeS/WAN will not overwrite them if they pre-exist. "Entropy" is the degree of unknown-ness. The kernel collects the times of unpredictable events such as keystrokes and packet arrivals, and after digestion, /dev/random puts them out to consumers such as key generators, so the keys are equally unpredictable (by the enemy). The UML has much fewer unpredictable events, hence much slower entropy production. Some motherboards have a hardware random generator, and this is the best source of entropy, but is beyond the reach of UML. Here's a case where the UML should pass an activity to the host kernel rather than trying to do for itself. So here's a feature request: On the command line you can list major numbers and minor ranges, and maybe non-I/O syscalls as well, such that all (userspace) access should be re-executed by UML on the host kernel, and the results returned without interpretation. So /dev/random would be the host's entropy pool (with the hardware generator if available). If the UML executing user had permissions for a particular USB device, RAID array, etc. on the host, it could be used even though UML does not have general permission to monkey with USB or block devices. Hmm, how would it work? Guest user opens /dev/xyz. UML discovers that the major-minor combination should be passed through. It opens (as the executing user's self) /dev/xyz on the host, receives a host FD, and makes a control block accessible via the guest FD, which it passes back to the client. The client now does read-write-ioctl-close on that FD, and UML does the same syscall with the same arguments, on the host. Voila. This probably wouldn't extend to actually mounting block devices like USB memory drives or RAID, but it's a start. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: [EMAIL PROTECTED] http://www.math.ucla.edu/~jimc (q.v. for PGP key)
