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

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

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.

> 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
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

> 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.

Perry
-- 
Perry E. Metzger                perry%piermont.com@localhost