NetBSD Problem Report #40739
From root@blackhole.ait.iastate.edu Tue Feb 24 17:57:44 2009
Return-Path: <root@blackhole.ait.iastate.edu>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id 58E7363C1C0
for <gnats-bugs@gnats.NetBSD.org>; Tue, 24 Feb 2009 17:57:44 +0000 (UTC)
Message-Id: <20090224165335.5D39220660F0@blackhole.ait.iastate.edu>
Date: Tue, 24 Feb 2009 10:53:35 -0600 (CST)
From: gendalia@iastate.edu
Reply-To: gendalia@iastate.edu
To: gnats-bugs@gnats.NetBSD.org
Subject: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
X-Send-Pr-Version: 3.95
>Number: 40739
>Category: port-xen
>Synopsis: no entropy sources found
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: bouyer
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Feb 24 18:00:00 +0000 2009
>Closed-Date: Mon May 03 04:11:49 +0000 2010
>Last-Modified: Mon May 03 04:11:49 +0000 2010
>Originator: Tracy J. Di Marco White
>Release: NetBSD 5.0_RC2 20090209 from build cluster
>Organization:
Iowa State University
>Environment:
NetBSD kerberos-1.iastate.edu 5.0_RC2 NetBSD 5.0RC2 (XEN3PAE_DOMU) #0: Mon Feb 9 10:22:33 UTC 2009 builds@b4.netbsd.org:/home/builds/ab/netbsd-5-0-RC2/i386/200902090142Z-obj/home/builds/ab/netbsd-5-0-RC2/src/sys/arch/i386/compile/XEN3PAE_DOMU i386
Architecture: i386
Machine: i386
>Description:
Running MIT's kerberos server, kadmind (for kerberos 5) will not start due
to a lack of entropy. There are no entropy sources available to generate
entropy from.
% rndctl -ls
Source Bits Type Flags
4346 bits mixed into pool
0 bits currently stored in pool (max 4096)
0 bits of entropy discarded due to full pool
4346 hard-random bits generated
210118 pseudo-random bits generated
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@netbsd.org
Cc: port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Tue, 24 Feb 2009 19:56:41 +0100
On Tue, Feb 24, 2009 at 06:00:01PM +0000, gendalia@iastate.edu wrote:
> >Environment:
> NetBSD kerberos-1.iastate.edu 5.0_RC2 NetBSD 5.0RC2 (XEN3PAE_DOMU) #0: Mon Feb 9 10:22:33 UTC 2009 builds@b4.netbsd.org:/home/builds/ab/netbsd-5-0-RC2/i386/200902090142Z-obj/home/builds/ab/netbsd-5-0-RC2/src/sys/arch/i386/compile/XEN3PAE_DOMU i386
> Architecture: i386
> Machine: i386
> >Description:
> Running MIT's kerberos server, kadmind (for kerberos 5) will not start due
> to a lack of entropy. There are no entropy sources available to generate
> entropy from.
> % rndctl -ls
> Source Bits Type Flags
> 4346 bits mixed into pool
> 0 bits currently stored in pool (max 4096)
> 0 bits of entropy discarded due to full pool
> 4346 hard-random bits generated
> 210118 pseudo-random bits generated
the problem in the case of a Xen domU is that there's no good source
of entropy. On native systems we use the hard disk as a source
of entropoy; but on a domU it's disabled because others domU could interfere
with it.
rndctl should show xennets as a possible source of entropy, but it has
to be enabled manually.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: "Tracy J. Di Marco White" <gendalia@iastate.edu>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Tue, 24 Feb 2009 16:02:42 CST
In message <20090224214003.3D27163C1C0@www.NetBSD.org>, Manuel Bouyer writes:
} > % rndctl -ls
} > Source Bits Type Flags
} > 4346 bits mixed into pool
} > 0 bits currently stored in pool (max 4096)
} > 0 bits of entropy discarded due to full pool
} > 4346 hard-random bits generated
} > 210118 pseudo-random bits generated
}
} the problem in the case of a Xen domU is that there's no good source
} of entropy. On native systems we use the hard disk as a source
} of entropoy; but on a domU it's disabled because others domU could interfere
} with it.
} rndctl should show xennets as a possible source of entropy, but it has
} to be enabled manually.
How would I enable it manually?
Tracy J. Di Marco White
Information Technology Services
Iowa State University
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: "Tracy J. Di Marco White" <gendalia@iastate.edu>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Wed, 25 Feb 2009 20:20:33 +0100
On Tue, Feb 24, 2009 at 04:02:42PM -0600, Tracy J. Di Marco White wrote:
>
> In message <20090224214003.3D27163C1C0@www.NetBSD.org>, Manuel Bouyer writes:
> } > % rndctl -ls
> } > Source Bits Type Flags
> } > 4346 bits mixed into pool
> } > 0 bits currently stored in pool (max 4096)
> } > 0 bits of entropy discarded due to full pool
> } > 4346 hard-random bits generated
> } > 210118 pseudo-random bits generated
> }
> } the problem in the case of a Xen domU is that there's no good source
> } of entropy. On native systems we use the hard disk as a source
> } of entropoy; but on a domU it's disabled because others domU could interfere
> } with it.
> } rndctl should show xennets as a possible source of entropy, but it has
> } to be enabled manually.
>
> How would I enable it manually?
'rndctl -l' should list it; you should be able to enable it with
'rndctl -c'
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: "Tracy J. Di Marco White" <gendalia@iastate.edu>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Wed, 25 Feb 2009 13:37:25 CST
In message <20090225192033.GA353@antioche.eu.org>, Manuel Bouyer writes:
}On Tue, Feb 24, 2009 at 04:02:42PM -0600, Tracy J. Di Marco White wrote:
}>
}> In message <20090224214003.3D27163C1C0@www.NetBSD.org>, Manuel Bouyer writes:
}> } > % rndctl -ls
}> } > Source Bits Type Flags
}> } > 4346 bits mixed into pool
}> } > 0 bits currently stored in pool (max 4096)
}> } > 0 bits of entropy discarded due to full pool
}> } > 4346 hard-random bits generated
}> } > 210118 pseudo-random bits generated
}> }
}> } the problem in the case of a Xen domU is that there's no good source
}> } of entropy. On native systems we use the hard disk as a source
}> } of entropoy; but on a domU it's disabled because others domU could interfere
}> } with it.
}> } rndctl should show xennets as a possible source of entropy, but it has
}> } to be enabled manually.
}>
}> How would I enable it manually?
}
}'rndctl -l' should list it; you should be able to enable it with
}'rndctl -c'
'rndctl -l' doesn't list any devices, as shown above.
Tracy J. Di Marco White
Information Technology Services
Iowa State University
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: "Tracy J. Di Marco White" <gendalia@iastate.edu>
Cc: gnats-bugs@NetBSD.org, port-xen-maintainer@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Wed, 25 Feb 2009 22:38:20 +0100
On Wed, Feb 25, 2009 at 01:37:25PM -0600, Tracy J. Di Marco White wrote:
> 'rndctl -l' doesn't list any devices, as shown above.
I see, if_xennet_xenbus.c is missing a call to rnd_attach_source().
It can probably be cut-n-pasted from if_xennet.c.
I'll have a look next week, unless someone beats me
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Christoph Egger <Christoph_Egger@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gendalia@iastate.edu
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Thu, 26 Feb 2009 00:14:09 +0100
This is a multi-part message in MIME format.
--------------040104040709060704000107
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Manuel Bouyer wrote:
> On Wed, Feb 25, 2009 at 01:37:25PM -0600, Tracy J. Di Marco White wrote:
> > 'rndctl -l' doesn't list any devices, as shown above.
>
> I see, if_xennet_xenbus.c is missing a call to rnd_attach_source().
> It can probably be cut-n-pasted from if_xennet.c.
> I'll have a look next week, unless someone beats me
Tracy: If this patch is ok, I'll commit it.
Christoph
--------------040104040709060704000107
Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0";
name="xennet_entropy.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="xennet_entropy.diff"
Index: sys/arch/xen/xen/if_xennet_xenbus.c
===================================================================
RCS file: /cvsroot/src/sys/arch/xen/xen/if_xennet_xenbus.c,v
retrieving revision 1.33
diff -u -p -r1.33 if_xennet_xenbus.c
--- sys/arch/xen/xen/if_xennet_xenbus.c 8 Feb 2009 19:05:50 -0000 1.33
+++ sys/arch/xen/xen/if_xennet_xenbus.c 25 Feb 2009 23:11:47 -0000
@@ -378,6 +378,11 @@ xennet_xenbus_attach(device_t parent, de
panic("%s: can't establish soft interrupt",
device_xname(self));
+#if NRND > 0
+ rnd_attach_source(&sc->sc_rnd_source, device_xname(sc->sc_dev),
+ RND_TYPE_NET, 0);
+#endif
+
/* initialise shared structures and tell backend that we are ready */
xennet_xenbus_resume(sc);
}
--------------040104040709060704000107--
From: Christoph Badura <bad@bsd.de>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Thu, 26 Feb 2009 12:45:23 +0100
On Tue, Feb 24, 2009 at 07:56:41PM +0100, Manuel Bouyer wrote:
> the problem in the case of a Xen domU is that there's no good source
> of entropy. On native systems we use the hard disk as a source
> of entropoy; but on a domU it's disabled because others domU could interfere
> with it.
Entropy collection from xbd isn't disabled in Xen2 domUs. I'm not sure I
buy the assertion that other domUs could interfere with the entropy collection.
And if they did, wouldn't that then be true for xennet, too?
What is the actual way to interfere with entropy collection, BTW?
> rndctl should show xennets as a possible source of entropy, but it has
> to be enabled manually.
I guess we should enable that by default then. Proably not only for domU
as diskless machines need an entropy source, too.
--chris
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Thu, 26 Feb 2009 20:20:06 +0100
On Thu, Feb 26, 2009 at 12:45:23PM +0100, Christoph Badura wrote:
> On Tue, Feb 24, 2009 at 07:56:41PM +0100, Manuel Bouyer wrote:
> > the problem in the case of a Xen domU is that there's no good source
> > of entropy. On native systems we use the hard disk as a source
> > of entropoy; but on a domU it's disabled because others domU could interfere
> > with it.
>
> Entropy collection from xbd isn't disabled in Xen2 domUs.
that's a mistake.
> I'm not sure I
> buy the assertion that other domUs could interfere with the entropy collection.
I'm not a crypto expert, but another domU can cause predictible delays in
disk I/O and I suspect this is bad for entropy.
> And if they did, wouldn't that then be true for xennet, too?
it is, not only for xennet but for any interface on a shared network.
that's why entropy collection on network interfaces is disabled by default
>
> What is the actual way to interfere with entropy collection, BTW?
AFAIK entropy collection on peripherals is based on delays. Anything that
can cause or add predictible delays to I/O can interfere.
>
> > rndctl should show xennets as a possible source of entropy, but it has
> > to be enabled manually.
>
> I guess we should enable that by default then. Proably not only for domU
> as diskless machines need an entropy source, too.
security experts needs to be consulted on this.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Christoph Badura <bad@bsd.de>
To: gnats-bugs@netbsd.org
Cc: Manuel Bouyer <bouyer@antioche.eu.org>
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Mon, 2 Mar 2009 23:32:52 +0100
[I have changed the order of the quoted text slightly.]
On Thu, Feb 26, 2009 at 08:20:06PM +0100, Manuel Bouyer wrote:
> On Thu, Feb 26, 2009 at 12:45:23PM +0100, Christoph Badura wrote:
> > I'm not sure I
> > buy the assertion that other domUs could interfere with the entropy collection.
> I'm not a crypto expert, but another domU can cause predictible delays in
> disk I/O and I suspect this is bad for entropy.
> > What is the actual way to interfere with entropy collection, BTW?
> AFAIK entropy collection on peripherals is based on delays. Anything that
> can cause or add predictible delays to I/O can interfere.
There are two flaws in your argument: 1) entropy collection isn't based on
delay and 2) you haven't described an attack.
Entropy collection on peripherals is *not* based on delay. It is based on
jitter in the timing of interrupt delivery relative to a clock source in
the system. So, even if the I/Os would be delayed there would still be a
bit of jitter in the interrupt delivery and that jitter is the entropy that
is extracted.
rnd(4) filters samples for non-linear jitter and credits them with 1 bit of
entropy if they are judged random enough.
Assuming that someone is indeed able to "cause predictible delays in disk I/O"
what effects would that have?
The attacker can reduce the amount of entropy that is collected in a given
time frame. But there's still randomness to be found in anyway. Obviously
this situation is preferable to not collecting any entropy at all.
This isn't a reason to prevent the collection of entropy or to disable it
by default. If users run their domUs in such a hostile environment they
can disable entropy collection by themselves.
The commonly discussed attack is that an attacker may be able to figure
out the random data was handed to a security sensitive processes, say to
be used as nonce or key material. However, for this attack you need to
know the exact state of the random pool. And you can't know that by just
manipulating the delay of the I/O requests. You'd need access to the
actual memory that stores the data.
Neither scenario is a reason not to try to collect entropy from as many
sources as possible -- quite the contrary actually.
If you fear a flaw in or a breakdown of the algorithms inside rnd(4) that
is an orthogonal issue.
> > And if they did, wouldn't that then be true for xennet, too?
> it is, not only for xennet but for any interface on a shared network.
> that's why entropy collection on network interfaces is disabled by default
But being connected to a switch is *not* being on a shared network, because
it hides traffic from other machines in the same logical (sub) network.
> > Entropy collection from xbd isn't disabled in Xen2 domUs.
> that's a mistake.
I wonder on what authority you claim that? To me it looks very much like
you are pulling vague arguments out of thin air and demand that a crypto
researcher refutes them. If you want to continue this argument, why don't
you find and expert that backs up your claims?
I wonder on what authority you claim that? Your arguments seem very vague
to me. Please find and expert to back up your claims.
If you want to discuss this further, I suggest we take it to tech-security.
In the mean-time I don't see why we should cripple rnd(4) in domUs by default.
Users who are extra paranoid can disable the sources with rndctl(8).
--chris
P.S. yes, I looked at quite a bit of background literature on this and
read the rnd(4) sources.
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Christoph Badura <bad@bsd.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2
XEN3PAE_DOMU
Date: Tue, 3 Mar 2009 11:02:01 +0100
On Mon, Mar 02, 2009 at 11:32:52PM +0100, Christoph Badura wrote:
> [I have changed the order of the quoted text slightly.]
>
> On Thu, Feb 26, 2009 at 08:20:06PM +0100, Manuel Bouyer wrote:
> > On Thu, Feb 26, 2009 at 12:45:23PM +0100, Christoph Badura wrote:
> > > I'm not sure I
> > > buy the assertion that other domUs could interfere with the entropy collection.
> > I'm not a crypto expert, but another domU can cause predictible delays in
> > disk I/O and I suspect this is bad for entropy.
> > > What is the actual way to interfere with entropy collection, BTW?
> > AFAIK entropy collection on peripherals is based on delays. Anything that
> > can cause or add predictible delays to I/O can interfere.
>
> There are two flaws in your argument: 1) entropy collection isn't based on
> delay and 2) you haven't described an attack.
>
> Entropy collection on peripherals is *not* based on delay. It is based on
> jitter in the timing of interrupt delivery relative to a clock source in
> the system. So, even if the I/Os would be delayed there would still be a
> bit of jitter in the interrupt delivery and that jitter is the entropy that
> is extracted.
OK, so you call jitter what I call delay. Whatever ...
>
> rnd(4) filters samples for non-linear jitter and credits them with 1 bit of
> entropy if they are judged random enough.
>
> Assuming that someone is indeed able to "cause predictible delays in disk I/O"
> what effects would that have?
>
> The attacker can reduce the amount of entropy that is collected in a given
> time frame. But there's still randomness to be found in anyway. Obviously
> this situation is preferable to not collecting any entropy at all.
> This isn't a reason to prevent the collection of entropy or to disable it
> by default. If users run their domUs in such a hostile environment they
> can disable entropy collection by themselves.
>
> The commonly discussed attack is that an attacker may be able to figure
> out the random data was handed to a security sensitive processes, say to
> be used as nonce or key material. However, for this attack you need to
> know the exact state of the random pool. And you can't know that by just
> manipulating the delay of the I/O requests. You'd need access to the
> actual memory that stores the data.
>
> Neither scenario is a reason not to try to collect entropy from as many
> sources as possible -- quite the contrary actually.
OK, so why is entropy collection disabled by default for all network
interfaces ? Your demonstration would apply to network interfaces as well.
>
> If you fear a flaw in or a breakdown of the algorithms inside rnd(4) that
> is an orthogonal issue.
>
> > > And if they did, wouldn't that then be true for xennet, too?
> > it is, not only for xennet but for any interface on a shared network.
> > that's why entropy collection on network interfaces is disabled by default
>
> But being connected to a switch is *not* being on a shared network, because
> it hides traffic from other machines in the same logical (sub) network.
not really, as another host on the same switch can affect jitter for
a given host (even if they are on different vlans).
>
> > > Entropy collection from xbd isn't disabled in Xen2 domUs.
> > that's a mistake.
>
> I wonder on what authority you claim that? To me it looks very much like
> you are pulling vague arguments out of thin air and demand that a crypto
> researcher refutes them. If you want to continue this argument, why don't
> you find and expert that backs up your claims?
Why don't you find one that back yours ?
In this regard domU I/Os works in the exact same way as network I/O though
a hub or a switch: requests from different domUs are multiplexed to the
same ressource. Thinks would be different if the I/O
>
> I wonder on what authority you claim that?
I don't have authority; but until I find someone which can show that
an attack is not possible though xen block devices, I'll be conservative.
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Christoph Badura <bad@bsd.de>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Tue, 3 Mar 2009 23:12:21 +0100
On Tue, Mar 03, 2009 at 11:02:01AM +0100, Manuel Bouyer wrote:
> On Mon, Mar 02, 2009 at 11:32:52PM +0100, Christoph Badura wrote:
> OK, so why is entropy collection disabled by default for all network
> interfaces ? Your demonstration would apply to network interfaces as well.
I don't know as I wasn't involved in that discussion. If you go and grovel
the mailing list archives, maybe you can find something.
> > But being connected to a switch is *not* being on a shared network, because
> > it hides traffic from other machines in the same logical (sub) network.
> not really, as another host on the same switch can affect jitter for
> a given host (even if they are on different vlans).
Oh, sure they can affect that. It isn't sufficient to affect it in any
random way, though. You have to affect it so that the stream of random
bits being output becomes predictable to some degree.
> Why don't you find one that back yours ?
I already took steps in that direction. I invited Steven Bellovin and
Perry Metzger to give their opinion on the matter.
Would these two be acceptable to you?
> I don't have authority; but until I find someone which can show that
> an attack is not possible though xen block devices, I'll be conservative.
If you are that concerned about a possible attack, you should rip out the
calls to rnd_add_uint32() from the network drivers.
--chris
Responsible-Changed-From-To: port-xen-maintainer->bouyer
Responsible-Changed-By: bouyer@NetBSD.org
Responsible-Changed-When: Sun, 20 Sep 2009 10:20:47 +0000
Responsible-Changed-Why:
I added rnd(4) support to xbd and xennet a few months ago
State-Changed-From-To: open->feedback
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Sun, 20 Sep 2009 10:20:47 +0000
State-Changed-Why:
All supported branches have rnd(4) support on xbd and xennet, off by
default but that can be enabled with rndctl. Is it ok for you ?
State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 03 May 2010 04:11:49 +0000
State-Changed-Why:
Feedback timeout.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home