PV random device

PV random device

[Sarah Newman]

Greetings,

We would like to use something like virtio-rng http://wiki.qemu-project.org/Features-Done/VirtIORNG with PVM domUs and since the wiki page on virtio
http://wiki.xen.org/wiki/Virtio_On_Xen says the wiki page is out of date, what is the current status?

Would a native xen driver be likely to be accepted upstream? If so, is there anyone already working on one?

Thanks, Sarah

Re: PV random device

[Andy Smith]

Hi,

On Mon, Oct 05, 2015 at 06:33:49PM -0700, Sarah Newman wrote:
> We would like to use something like virtio-rng http://wiki.qemu-project.org/Features-Done/VirtIORNG with PVM domUs and since the wiki page on virtio
> http://wiki.xen.org/wiki/Virtio_On_Xen says the wiki page is out of date, what is the current status?

I'm sorry, I do not know the answer to your question, but while the
subject of virtio-rng has been brought up I wanted to mention
something related.

As you're no doubt aware, domUs being starved of entropy can be a
problem when they are doing crypto-intensive things like HTTPS,
VPNs, PGP and so on. The blocking nature of /dev/random can cause
performance problems.

So, I've been keeping (PV) domUs topped up with entropy by giving
them access to hardware RNGs (initially Entropy Keys, but since the
company making them failed I've switched to OneRNGs).

However, a lot of smart people tell me I'm doing this wrong:

    http://www.2uo.de/myths-about-urandom/

Basically they tell me to just make everything use /dev/urandom
instead. The above article suggests that the only time /dev/random
is better than urandom is on Linux boot when it needs to seed the
PRNG.

That said, I'm still left with a lot of software that wants to use
/dev/random and can't be told to do otherwise. Symlinking random to
urandom seems like a rather excessive thing to suggest people do
(domU admins are my customers).

It may just be the path of least resistance for me to continue
telling my customers to point their stuff at my hardware RNGs even
if it is the wrong solution. And then hopefully switch to using
virtio-rng so my customers need not know about the hardware RNGs.

But doing the technically wrong thing hurts my sensibilities a bit.

Has anyone got any thoughts on that?

Cheers,
Andy

-- 
> The optimum programming team size is 1.
Has Jurassic Park taught us nothing?
 — pfilandr

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: PV random device

[Sarah Newman]

On 10/05/2015 08:35 PM, Andy Smith wrote:

> So, I've been keeping (PV) domUs topped up with entropy by giving
> them access to hardware RNGs (initially Entropy Keys, but since the
> company making them failed I've switched to OneRNGs).

This is not a satisfactory solution for us because even if we were willing to do USB passthrough, the number of hardware devices needed would be
expensive and difficult to manage. A TPM and presumably VTPM can provide entropy
http://www.berthon.eu/2015/using-tpm-as-a-source-of-randomness-entropy/ but again it would be difficult for us to implement globally in the
conceivable future as we don't have TPM modules in all of our servers. The VTPM might work for you though.

I guess another solution might be to have a VTPM backend in the dom0 that only provides entropy and not any of the other functionality, but I don't
know enough about TPMs to know if that would be practical.

Re: PV random device

[Andy Smith]

Hi Sarah,

On Mon, Oct 05, 2015 at 09:12:47PM -0700, Sarah Newman wrote:
> On 10/05/2015 08:35 PM, Andy Smith wrote:
> > So, I've been keeping (PV) domUs topped up with entropy by giving
> > them access to hardware RNGs (initially Entropy Keys, but since the
> > company making them failed I've switched to OneRNGs).
> 
> This is not a satisfactory solution for us because even if we were
> willing to do USB passthrough, the number of hardware devices
> needed would be expensive and difficult to manage.

I don't find it a problem as:

- Your typical EntropyKey or OneRNG can generate quite a bit of
  entropy. Maybe 32 kilobytes per second for ~$50 each.

- You can access them over the network so no USB passthrough needed.

- Making it opt-in means only people who actually know and care what
  entropy is will use it. :)

So for me it's a somewhat hacky but still scalable solution. My main
concern is that it's going to some length to provide a service that
isn't actually required.

Cheers,
Andy

-- 
> I'd be interested to hear any (even two word) reviews of their sofas…
Provides seating.
 — Andy Davidson

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: PV random device

[Sarah Newman]

On 10/05/2015 09:29 PM, Andy Smith wrote:

> I don't find it a problem as:
> 
> - Your typical EntropyKey or OneRNG can generate quite a bit of
>   entropy. Maybe 32 kilobytes per second for ~$50 each.
> 
> - You can access them over the network so no USB passthrough needed.

Yes, I'm implementing something similar (entropy as a service) but I agree it's a hackish solution.

Re: PV random device

[Steven Haigh]

On 2015-10-06 15:29, Andy Smith wrote:
> - Your typical EntropyKey or OneRNG can generate quite a bit of
>   entropy. Maybe 32 kilobytes per second for ~$50 each.

If you can get one... :)

> - You can access them over the network so no USB passthrough needed.

Care to give details on this? I've got a HWRNG on a system that I'd like 
to 'share' the entropy source out - but haven't found anything to do 
this.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897

Re: PV random device

[Andy Smith]

Hi Steven

On Tue, Oct 06, 2015 at 03:50:10PM +1100, Steven Haigh wrote:
> On 2015-10-06 15:29, Andy Smith wrote:
> >- Your typical EntropyKey or OneRNG can generate quite a bit of
> >  entropy. Maybe 32 kilobytes per second for ~$50 each.
> 
> If you can get one... :)

Yeah, EntropyKeys aren't really obtainable any more but I have some
OneRNGs for if my installed EntropyKeys ever die.

> >- You can access them over the network so no USB passthrough needed.
> 
> Care to give details on this? I've got a HWRNG on a system that I'd
> like to 'share' the entropy source out - but haven't found anything
> to do this.

Okay so the people who made EntropyKey made two pieces of software
called ekeyd and ekeyd-egd. They're available with source here:

    http://www.entropykey.co.uk/download/

They haven't been modified since 2009 or something, but they still
work.

ekeyd-egd is what you install on client hosts (e.g. VMs). You point
it at an IP address that will serve it entropy in EGD format and it
stuffs that entropy into the client hosts's /dev/random. Despite the
name it is not specific to the EntropyKey.

ekeyd is what you install on the host that has the EntropyKey.

Now, ekeyd is obviously specific to the EntropyKey, so if not using
an EntropyKey you'd probably need to replace that part with a daemon
that serves your /dev/random out in EGD mode.

I haven't yet tried to do this because my EntropyKeys still work and
making use of my OneRNGs is a future project. I think this should
work:

    http://www.vanheusden.com/entropybroker/

That was going to be the first thing I looked at anyway.

But again as I say, that article I posted earlier contains a bunch
of smart crypto people saying that all of this is unnecessary. So
should we be enabling it?

Cheers,
Andy

-- 
"SCSI is usually fixed by remembering that it needs three terminations: One at
 each end of the chain. And the goat." — Andrew McDonald

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: PV random device

[Sarah Newman]

On 10/05/2015 10:18 PM, Andy Smith wrote:

> But again as I say, that article I posted earlier contains a bunch
> of smart crypto people saying that all of this is unnecessary. So
> should we be enabling it?

Even if only urandom is considered necessary, how is the initial seed for urandom being generated and securely provided (if externally generated) to
the guest?

ubuntu has a client/server "entropy as a service" pollen https://github.com/dustinkirkland/pollen and pollinate
https://github.com/dustinkirkland/pollinate which writes to /dev/urandom at boot. To my best knowledge a total of zero non-ubuntu derived
distributions have adopted it, though I can't comment on why.

MirageOS has come up with https://github.com/mirage/xentropyd and https://github.com/mirage/mirage-entropy which appears to be a layer on top of
channels http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/channel.txt I don't know if this is the preferred implementation method. I also
haven't found a front-end implementation other than in MirageOS.

Re: PV random device

[Ian Campbell]

On Mon, 2015-10-05 at 18:33 -0700, Sarah Newman wrote:
> Greetings,
> 
> We would like to use something like virtio-rng 
> http://wiki.qemu-project.org/Features-Done/VirtIORNG with PVM domUs and
> since the wiki page on virtio
> http://wiki.xen.org/wiki/Virtio_On_Xen says the wiki page is out of date,
> what is the current status?
> 
> Would a native xen driver be likely to be accepted upstream?

My two pence is that this seems like a reasonable application of the
channels[0] interface to provide a simple device that when read spits out
random bytes, which can then be fed into rngd (or whatever it is called).

>  If so, is there anyone already working on one?

It comes up occasionally, most recently was 
http://lists.xen.org/archives/html/xen-devel/2015-02/msg00003.html . CCing
Dave.

Cheers,
Ian.

[0] http://xenbits.xen.org/docs/unstable/misc/channel.txt