svn commit: r274739 - head/sys/mips/conf

[Mark R V Murray]

> On 25 Nov 2014, at 17:11, Warner Losh <imp at bsdimp.com> wrote:
>> The repeatability of the boot sequence of hardware like this is nearly
>> perfect at the resolution we're measuring.  While that may be bad for
>> gathering entropy, it's a wonderful thing when you're debugging, because
>> problems that would be almost impossible to nail down on modern complex
>> hardware are 100% reproducible by just hitting the reset button.  That
>> reproducibility extends all the way into multiuser mode unless there is
>> a network connection where packet arrival times start adding
>> interrupt-based entropy.
> 
> Yea, every boot it is the same registers that are being read, in the
> same sequence, resulting in very similar cache patterns and performance
> profiles. I’d be surprised if anything apart from the ethernet chip’s
> state was different between boots. And even the ethernet’s stuff has
> a low variance until interrupts are turned on…

Things are far from perfect, but not entirely unexpected. I’m well
aware that PCs are low-entropy beasties at the best of times as we have
to struggle like crazy to get what we have. The bottom-end boxes with
no high-resolution timers are clearly going to be much worse.

For real security, I guess the answer is cached entropy in files that
are preserved over a boot and deleted straight after boot.

Ian’s case, where security is not an issue, should be solvable by
getting the random(4) driver to be content with whatever it gets
from the boot entropy, crappy as it is, in a way that doesn’t offer
an attack vector. This should be doable.

M
-- 
Mark R V Murray