Darren J Moffat wrote:
> Yannick Robert wrote:
>
>> Hello
>>
>> it seems i have the same problem after zfs boot installation (following this
>> setup on a snv_69 release
>> http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/ ). The
>> outputs from the requested command are similar to the outputs posted by
>> dev2006.
>>
>> Reading this page, i found no solution concerning the /dev/random problem.
>> Is there somewhere a procedure to repair my install ?
>>
To answer Yannick's question, the /dev/random warning message does not
indicate
any problem with the install and can be ignored.
> ...
>
> Unlike UFS when we do a ZFS boot we do use the in kernel interface to
> /dev/random (random_get_bytes) before svc://system/cryptosvc has run.
>
To be exact, the API used by ZFS kernel module is
random_get_pseudo_bytes().
> The message you are seeing is from KCF saying that it has a random pool
> but nothing providing entropy to it. This is because swrand hasn't yet
> registered with kcf.
>
We had a similar issue with SCTP where in it uses the kernel API
random_get_pseudo_bytes() before swrand could register.
The solution we had there was to load swrand directly. From
uts/sparc/ip/Makefile
78 #
79 # Depends on md5 and swrand (for SCTP). SCTP needs to depend on
80 # swrand as it needs random numbers early on during boot before
81 # kCF subsystem can load swrand.
82 #
83 LDFLAGS += -dy -Nmisc/md5 -Ncrypto/swrand -Nmisc/hook
-Nmisc/neti
I think we can do a similar thing here. The zfs (or is it zfs-root ?)
kernel module
can have crypto/swrand as a dependency. I see that uts/sparc/zfs/Makefile
lists drv/random as a dependency. This is not needed because the
API is in modstubs now and it is not implemented in drv/random any more.
That can be replaced with crypto/swrand.
swrand does not need any crypto signature verification. So, it can
safely be loaded
early on during boot.
> Now this was all done prior to newboot and SMF and part of the goal of
> why KCF works this way with software providers is was to ensure no boot
> time performance regressions by doing load on demand rather than forcing
> the loading of all modules at boot time.
Yes. This requirement added a lot of complexity to KCF.
> With newboot on x86, and soon
> on SPARC, the swrand module will be in the boot archive anyway.
>
That would be great. It is cleaner and will remove the need for ad hoc
solutions like above.
-Krishna
