[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/xen/xen
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:
> 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 E. Metzger perry%piermont.com@localhost
Main Index |
Thread Index |