H. Peter Anvin wrote:
> However, the big issue with this is that it's recursive... what
causes this to
> be invoked... probably an interrupt, which is going to have been
> invoked by a timer, quite possible the TSC deadline timer. Oops.
I was assuming that drivers, responding to an interrupt from some
external event, would want to make this call.
Such as a network driver. The canonical example is an entropy-starved
server that doesn't see much light at all, let alone a local user with a
mouse. But such a server does see plenty of packets. Packets that go
through various delays before getting to the ethernet port.
And even if an outside observer could get past the physical security
that isolates such a poor starved server and tap at the ethernet port,
an ethernet port is still many centimeters, a lot of gates, and even
some firmware away from the IRQ pin, and that pin itself is some
distance from the TSC. Knowing that LSB is extremely hard. Knowing
exactly when the LSB is going to be sampled is extremely hard. Knowing
both presents very real theoretical hurdles. And those hurdles get much
higher with every meter of distance.
> at the very least I would multiply the low 32 bits of
> the TSC with a 32-bit prime number before mixing.
Two points:
1. Why look at the high-order bits? How are they going to have values
that cannot be inferred? If you are looking for entropy, the low-order
bits is where they're going keep it. (Think Willie Sutton.) If looking
at the low-byte is cheaper, then let's be cheap. If, however, if
looking at more bytes *is* as cheap, then there is no harm. But in any
case let's keep the code lean enough that it can be called from an
interrupt service routine.
2. Don't confuse collecting entropy with how to mix the pool. Whether
or not to multiply by a prime number is the domain of how to mix the
pool. Possibly we need a patch on that, too, you might have a point
there, but that is a different question from whether we should be
allowed a function to use the TSC to mix the pool. Different issues.
-kb, the Kent who insists that it is better to credit no entropy and be
safe, than to collect no entropy and be certain.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
