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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Mar 03, 2009 at 03:37:20PM -0500, Perry E. Metzger wrote:
> 
> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
> >> 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.
> >
> > that's why they are disabled by default. For xennet I don't see it worse
> > than a real ethernet device in a bridge configuration.
> 
> I'm not sure a real ethernet device *is* an okay entropy source --
> networks are not exactly non-observable to outsiders -- but xen makes
> it somewhat worse by potentially quantizing jitter. The domU is not
> really running all the time -- it runs when the dom0 wants it to run.

Not exactly; it's when the hypervisor wants it to run.
This applies to the dom0 too, so collecting entropy from interrupt jitter
may be biased too for dom0.

> 
> > For xbd, I see it at the same level as xennet, or eventually better
> > if it has a dedicated disk.
> 
> Again, see above.
> 
> > Note that Xen 2 domU have had xennet as possible source of entropy,
> > and xbd as entropy source by default (this is probably not a good idea)
> > since day one.
> 
> I agree. Probably not the best move.
> 
> > Anyway, we don't have much choise for entropy sources if one is needed ...
> 
> Read the link I forwarded. My point is that if all you have are bad
> entropy sources, the choice is not "use predictable random numbers or
> use nothing", because that gives a false sense of security. It is

The fact that it's disabled by default should be a good hint that there
may be problems with it. Also, there are setups where interrupt jitter in
a domU can be a good source of entropy (if the domU is alone on its CPU
for example)

> possible to do something far better, which is to use a different
> method of generating cryptographic pseudo-random numbers
> entirely. Again, see:
> 
> http://www.mail-archive.com/cryptography%metzdowd.com@localhost/msg10062.html

Would someone vonlunteer to implement this in the kernel ?

> 
> > And it is, I think, well known that virtualisation has security issues
> > (at last on common x86 hardware).
> 
> That is not really a good excuse. People are using Xen instances for
> things like KDCs, we really should not be giving them a false sense of
> security in doing that.

Running a KDC in a Xen instance may not be a good idea, regardless of
the rnd issue.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--