tech-kern archive

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

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)



[[ sorry I've not been catching up on mailing list discussions as fast
as I had hoped to, and I'm way behind on following the entropy rototill. ]]

At Wed, 31 Mar 2021 00:12:31 +0000, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
Subject: Re: nothing contributing entropy in Xen domUs?  (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)
>
> This is false.  If the VM host provided a viornd(4) device then NetBSD
> would automatically collect, and count, entropy from the host, with no
> manual intervention.

I'll leave that idea to others more up-to-date on Xen PV drivers to
respond to.  Booting a -current GENERIC kernel (which has both Xen PV
and virtio(4) devices configured into it) in a "type='pvh'" domU only
attaches the xenbus PV devices, no virtio devices, so adding virtio
might be a bit of a much bigger task that will need further support on
at least the backend, and perhaps on the front-end too, especially to do
it without QEMU.  I haven't tried if virtio devices show up in an HVM
domU precisely because I'm trying to avoid having to run and rely on
QEMU (never mind any performance implications of HVM).

> > Finally, if the system isn't actually collecting entropy from a device,
> > then why the heck does it allow me to think it is (i.e. by allowing me
> > to enable it and show it as enabled and collecting via "rndctl -l")?
>
> The system does collect samples from all those devices.  However, they
> are not designed to be unpredictable and there is no good reliable
> model for just how unpredictable they are, so the system doesn't
> _count_ anything from them.  See https://man.NetBSD.org/entropy.4 for
> a high-level overview.

I'm not sure the word "count" appears in entropy(4) any context I can
make sense of it in w.r.t. what it means to "collect" but not "count"
entropy from those devices.

Worse the "Flags" shown by "rndctl -l" don't seem to be directly
documented (i.e. they're not described in rndctl(8)), and even on a
kernel running on real hardware I don't see the word "count" showing
there.

After looking at the source I'm not sure the descriptions of the
RND_FLAG_* values in rnd(4) help me much either.

Based on my vague understanding of all of this, perhaps you meant to say
"estimate", instead of "count"?  That would make more sense in the
context of what I read in rnd(4) and rndctl(8), though "estimate" still
seems a little vague in meaning to me.

In any case, I don't see why an xbd disk, or a xennet interface, can't
be treated exactly as if they were real hardware (i.e. in terms of
extracting entropy from their behaviour).  This is exactly what
virtualization is all about to me -- even for paravirtualization.  After
all in a threat-free world (i.e. specifically where I also trust other
domUs) their entropy is going to reflect (though maybe not exactly
mirror) the entropy of the underlying hardware and/or network traffic.
So (but maybe not by default) if I as the admin want to trust the
entropy available from an xbd(4) or xennet(4) device, then I should be
able to enable it with rndctl(8) and have it "count".

More importantly though the system shouldn't mislead me into thinking it
is "counting" entropy from a device when it is actually not.  If I had
seen that there were no sources estimating/counting/whatever entropy,
and I tried to enable one and was given a nice error message about this
not being possible, then I would have looked elsewhere to find out how
to give the system more bits of entropy.  As is in my Xen domU system
the output of "rndctl -l" leads me to believe all of my devices are
collecting both timing and value samples, and using either one or the
other to gather entropy (though with '-v' I don't see that any bits of
entropy have been added from any of those amy millions of collected
samples).

--
					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: pgpt8x_B7CUTv.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index