Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: regarding the changes to kernel entropy gathering



At Sun, 4 Apr 2021 18:47:23 -0700, Brian Buhrow <buhrow%nfbcal.org@localhost> wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Hello.  As I understand it, Greg ran into this problem on a xen domu.
> In checking my NetBSD-9 system running as a domu under xen-4.14.1,
> there is no rdrand or rdseed feature exposed to domu's by xen.  This
> observation is confirmed by looking at the xen command line reference
> page: https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

The problem in the domU was really just the very tip of the iceberg.

The dom0 exhibits the exact same problem and for the same reasons.

> and NetBSD doesn't trust the random sources provided by the xennet(4)
> and xbd(4) drivers.  Therefore, the only solution to get randomness
> working for the first time on a newlyinstalled domu is to write 32
> bytes to /dev/random.

It's not that the xbd(4) devices, etc. are not trusted as entropy
sources -- the new entropy system doesn't trust anything, real or
virtual, despite the documentation saying that it can be made to do so.

My patch fixes that bug.  It was very obvious once I understood the root
of the issue.

As a result my patch fixes the bug for Xen dom0 and domU.

Writing randomness to /dev/random is _NOT_ a general solution (though it
could be IFF it can be reliably taken from /dev/urandom AND IFF the rest
of the system and documentation is completely and adequately fixed to
match the new regime).

What perturbs me the most and makes me rather angry is that the rest of
the system, and the system documentation, continued to lie and mislead
me for days (and it didn't help that nobody who knew this was pointing
helpfully and clearly at the root of the problem).  So, my patch ALSO
restores the kernel's behaviour to match the documentation and tools
(specifically rndctl).  That the core of it it is just a two-line patch
makes this fix extremely satisfying.

--
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgpZfm6hrQNF6.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index