Re: kern/48028: Read from /dev/random hangs

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR kern/48028; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Aran Clauson <aran%otsys.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/48028: Read from /dev/random hangs
Date: Thu, 11 Jul 2013 23:30:02 +0000

    Date: Wed, 10 Jul 2013 16:10:01 +0000
    From: Aran Clauson <aran%otsys.com@localhost>
 
    The kernel build from 
 
    $ cvs -q up -dP -D '07/01/2013' 
 
    works just fine.  Kernel build from 
 
    $ cvs -q up -dP -D '07/02/2013' 
 
    hangs on cgdconfig at boot.  My current kernel source is from
    07/07/2013 with the same behavior as 07/02.
 
 OK, chances are it was triggered (if not caused) by
 <https://mail-index.netbsd.org/source-changes/2013/07/01/msg045202.html>.
 
    I am trying to read from /dev/random while I write this email.  I'm still
    waiting...  It took 1m25.524s.  
 
 Does banging on the keyboard or trackpad like a monkey affect that?
 
    I have to cgd devices.  One has a fixed key and contains my normal
    file systems.  The other uses a random key and contains my swap
    space.  Basically I followed the how to in the cgd manual.
 
    I'm not sure how to check if I have an entropy-file.  This,
    however, may be the problem.  /var is one of the cgd filesystems.
 
 In that case, /etc/rc.d/random_seed (which I mistakenly referred to as
 /etc/rc.d/rndctl in my last message) won't be able to load it after
 /var is mounted but before the swap cgd is randomkey-configured.
 
 As an alternative, if your root file system is unencrypted and
 persistently writable, you could store the entropy file in the root:
 
 1. Set random_file=/entropy in /etc/rc.conf.
 2. Add the command `rndseed /entropy' to your /boot.cfg file.
 
 That way, /etc/rc.d/random_seed will save entropy to /entropy on
 shutdown, and the boot loader (not /etc/rc) will load it early on
 boot, well before /etc/rc.d/cgd runs.
 
 However, while this might work around the problem, it doesn't explain
 why the problem recently arose.
 
    I will build a new kernel with these two options and report back.
 
 OK, thanks.  If that doesn't reveal anything, I can try putting more
 debugging messages in.
 
 
 As an aside, we really ought to do encrypted swap another way, not by
 configuring a cgd.  Encrypted swap ought to have zero administrative
 hassle (and be on by default...).