Re: CVS commit: src/sys/arch/xen/xen

["Perry E. Metzger" <perry%piermont.com@localhost>]

Manuel Bouyer <bouyer%netbsd.org@localhost> writes:
> Module Name:  src
> Committed By: bouyer
> Date:         Tue Mar  3 19:04:41 UTC 2009
>
> Modified Files:
>       src/sys/arch/xen/xen: if_xennet_xenbus.c xbd_xenbus.c
>
> Log Message:
> Fix rnd(4) support for Xen3 xennet
> Add rnd(4) support to Xen3 xbd
> Should fix port-xen/40739.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.33 -r1.34 src/sys/arch/xen/xen/if_xennet_xenbus.c
> cvs rdiff -u -r1.38 -r1.39 src/sys/arch/xen/xen/xbd_xenbus.c

This doesn't really fix things. What it does is fold what are possibly
quite low entropy sources into the RNG, leading the naive user to
believe that all is well. It is difficult to figure out whether or not
this method will actually work well, which makes it dangerous in a
security context -- the absence of proven problems is not the same as
the proven absence of problems.

I think we probably need an entirely different approach here. Either
there has to be some way to ask the dom0 for randomness, or one
probably has to start thinking in terms similar to the ones I was
bringing up in this discussion a while back:

http://www.mail-archive.com/cryptography%metzdowd.com@localhost/msg10062.html

i.e. a model that depends on a well modeled CPRNG like AES in counter
mode based on a long term secret rather than a poor source of random
numbers based on a difficult to measure source of entropy.

Perry