Source-Changes-D archive

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

Yet more reason I feel nervous about all of this.

We had a good solution for a while, when Intel started including RNGs
in their chip sets, but unfortunately they stopped that again.

My short term solution, as I said, is to just run AES in counter mode
and to live with the fact that the random numbers aren't as random as
one would want.

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

Fine, but that doesn't provide the user an actual workable solution that
gives them good assurance. We still need that.

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

It should be very little code. All you need is a pseudodevice that
stores a key and a counter (two variables). You also want an ioctl to
load the key, and a very small userland program that will let you load
the hash of a master key and the time.

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

I agree, but I know of a lot of people doing it. Including, I believe,
TNF.

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


Home | Main Index | Thread Index | Old Index