Re: [EMAIL PROTECTED]: Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.]
> This subthread in the Xen patch thread has now digressed onto discussions > about entropy and security. Perhaps you guys could add some points. Well, I can try. I don't think this answers any questions, but perhaps it informs the discussion. Apologies if the Cc: list is getting a bit bloated. > On 11 May 2006, at 01:33, Herbert Xu wrote: >>> But if sampling virtual events for randomness is really unsafe (is it >>> really?) then native guests in Xen would also get bad random numbers >>> and this would need to be somehow addressed. >> >> Good point. I wonder what VMWare does in this situation. > > Well, there's not much they can do except maybe jitter interrupt > delivery. I doubt they do that though. There are two aspects which are often confused. It doesn't sound like people are confused here, but I'll say it explicitly just to make sure: One is the concern that by feeding malicious data into the /dev/random pool, you can control its output. This can't happen; the input mixing is safe against that, which is why /dev/random is globally writeable. Whatever data you feed into the pool, you can't increase your level of knowledge about the state of it. So there is no need whatsoever to stop potentially bad data from being fed into the pool. The worst it can do is nothing. The second, which CAN happen, is an entropy estimation failure. The /dev/random system tries to guess by how much a given piece of input DECREASES an attacker's knowledge about the state of the pool. If it guesses wrong, it can produce output (which gives away information) beyond the limits of the unicity distance and then an attacker with unbounded computational power can figure out the state of the pool and thereby predict future output. Underestimating the entropy is always safe, so adding suspect data is fine as long as you give it a zero entropy score. But you need to find some entropy somewhere or you'll never make any progress. That's where it gets tricky. It's not what seed material you use (use it all), but what seed material do you TRUST? Also, for this second kind of problem, an attacker only has to KNOW what the data being introduced into the pool is (or, to be even more specific, know more about it than the entropy estimate thinks is possible), not control it in any way. Thus, there is no possible test of the input data itself which can prove an attacker's ignorance of it; some assumptions about its origin must be made. /dev/random's main entropy source is interrupt timing, based on the assumption that the real-world I/O devices are driven by sources at least partly uncorrelated with the processor clock. But if the interrupts are virtualized and come from hypervisor software, how unknown to an attacker are they? > The original complaint in our case was that we take entropy from > interrupts caused by other local VMs, as well as external sources. > There was a feeling that the former was more predictable and could form > the basis of an attack. I have to say I'm unconvinced: I don't really > see that it's significantly easier to inject precisely-timed interrupts > into a local VM. Certainly not to better than +/- a few microseconds. > As long as you add cycle-counter info to the entropy pool, the least > significant bits of that will always be noise. It's not a matter if injecting *controlled* interrupts, just *known* interrupts. If the duration of cross-VM interrupt delivery is predictable, an attacker reading the timestamp counter before sending a packet could predict the timestamp on arrival and figure out what's going into the pool. If that's the main source of entropy going in to the target domain and the attacker has a way to read the vast majority of the output of /dev/random there, an attacker has a chance to guess the fraction of /dev/random output they don't see. > The alternatives are unattractive: > 1. We have no good way to distinguish interrupts caused by packets > from local VMs versus packets from remote hosts. Both get muxed on the > same virtual interface. Doesn't the source MAC address offer a clue? > 2. An entropy front/back is tricky -- how do we decide how much > entropy to pull from domain0? How much should domain0 be prepared to > give other domains? How easy is it to DoS domain0 by draining its > entropy pool? Yuk. THAT, at least, is not terribly hard. It's exactly the same sort of fair CPU scheduling problem as has been solved many times before. As entropy comes in, credit it round-robin to various child domains. There's a pool in domain0 which can buffer a certain about of credit for child domains even if they don't want it yet. When that buffered credit reaches the limit that domain0 can store, it spills over and is allocated to other domains with non-full accounts. So after an initial accumulation period to fill up the buffers, the available entropy is divided evenly among all the domains that want it. I don't know how Xen works at all, whether it's
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Thursday 11 May 2006 18:48, Rick Jones wrote: > From the peanut gallery... > > Can remote TCP ISN's be considered a source of entropy these days? How > about checksums? Indirectly - we measure how long it takes to compute them. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From the peanut gallery... Can remote TCP ISN's be considered a source of entropy these days? How about checksums? rick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Thu, 11 May 2006 11:47:52 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > On Thursday 11 May 2006 09:49, Keir Fraser wrote: > > On 11 May 2006, at 01:33, Herbert Xu wrote: > > >> But if sampling virtual events for randomness is really unsafe (is it > > >> really?) then native guests in Xen would also get bad random numbers > > >> and this would need to be somehow addressed. > > > > > > Good point. I wonder what VMWare does in this situation. > > > > Well, there's not much they can do except maybe jitter interrupt > > delivery. I doubt they do that though. > > > > The original complaint in our case was that we take entropy from > > interrupts caused by other local VMs, as well as external sources. > > There was a feeling that the former was more predictable and could form > > the basis of an attack. I have to say I'm unconvinced: I don't really > > see that it's significantly easier to inject precisely-timed interrupts > > into a local VM. Certainly not to better than +/- a few microseconds. > > As long as you add cycle-counter info to the entropy pool, the least > > significant bits of that will always be noise. > > I think I agree - e.g. i would expect the virtual interrupts to have > enough jitter too. Maybe it would be good if someone could > run a few statistics on the resulting numbers? > > Ok the randomness added doesn't consist only of the least significant > bits. Currently it adds jiffies+full 32bit cycle count. I guess if it was > a real problem the code could be changed to leave out the jiffies and > only add maybe a 8 bit word from the low bits. But that would only > help for the para case because the algorithm for native guests > cannot be changed. > > > 2. An entropy front/back is tricky -- how do we decide how much > > entropy to pull from domain0? How much should domain0 be prepared to > > give other domains? How easy is it to DoS domain0 by draining its > > entropy pool? Yuk. > > I claim (without having read any code) that in theory you need to have solved > that problem already in the vTPM @) > The base question under all this is "how good does an entropy source have to be?" and then "what guarantees do we make about the entropy inputs used by /dev/random?". If we can resolve those, then the virtual environment answer should fall out. This is a area where the security tin-foil hat types take over, and it gets real hard to make "good enough" argument. People have built an expectation that /dev/random has really strong entropy, good enough to generate long term keys etc. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Thursday 11 May 2006 09:49, Keir Fraser wrote: > On 11 May 2006, at 01:33, Herbert Xu wrote: > >> But if sampling virtual events for randomness is really unsafe (is it > >> really?) then native guests in Xen would also get bad random numbers > >> and this would need to be somehow addressed. > > > > Good point. I wonder what VMWare does in this situation. > > Well, there's not much they can do except maybe jitter interrupt > delivery. I doubt they do that though. > > The original complaint in our case was that we take entropy from > interrupts caused by other local VMs, as well as external sources. > There was a feeling that the former was more predictable and could form > the basis of an attack. I have to say I'm unconvinced: I don't really > see that it's significantly easier to inject precisely-timed interrupts > into a local VM. Certainly not to better than +/- a few microseconds. > As long as you add cycle-counter info to the entropy pool, the least > significant bits of that will always be noise. I think I agree - e.g. i would expect the virtual interrupts to have enough jitter too. Maybe it would be good if someone could run a few statistics on the resulting numbers? Ok the randomness added doesn't consist only of the least significant bits. Currently it adds jiffies+full 32bit cycle count. I guess if it was a real problem the code could be changed to leave out the jiffies and only add maybe a 8 bit word from the low bits. But that would only help for the para case because the algorithm for native guests cannot be changed. > 2. An entropy front/back is tricky -- how do we decide how much > entropy to pull from domain0? How much should domain0 be prepared to > give other domains? How easy is it to DoS domain0 by draining its > entropy pool? Yuk. I claim (without having read any code) that in theory you need to have solved that problem already in the vTPM @) -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Thu, May 11, 2006 at 08:49:04AM +0100, Keir Fraser wrote:
>
> The alternatives are unattractive:
> 1. We have no good way to distinguish interrupts caused by packets
> from local VMs versus packets from remote hosts. Both get muxed on the
> same virtual interface.
> 2. An entropy front/back is tricky -- how do we decide how much
> entropy to pull from domain0? How much should domain0 be prepared to
> give other domains? How easy is it to DoS domain0 by draining its
> entropy pool? Yuk.
IMHO there just isn't enough real entropy to go around in one physical
machine without a proper HRNG. So either use urandom in all the guests
or for those that really have to use /dev/random, install a hardware
RNG (or wait for it :).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On 11 May 2006, at 01:33, Herbert Xu wrote: But if sampling virtual events for randomness is really unsafe (is it really?) then native guests in Xen would also get bad random numbers and this would need to be somehow addressed. Good point. I wonder what VMWare does in this situation. Well, there's not much they can do except maybe jitter interrupt delivery. I doubt they do that though. The original complaint in our case was that we take entropy from interrupts caused by other local VMs, as well as external sources. There was a feeling that the former was more predictable and could form the basis of an attack. I have to say I'm unconvinced: I don't really see that it's significantly easier to inject precisely-timed interrupts into a local VM. Certainly not to better than +/- a few microseconds. As long as you add cycle-counter info to the entropy pool, the least significant bits of that will always be noise. The alternatives are unattractive: 1. We have no good way to distinguish interrupts caused by packets from local VMs versus packets from remote hosts. Both get muxed on the same virtual interface. 2. An entropy front/back is tricky -- how do we decide how much entropy to pull from domain0? How much should domain0 be prepared to give other domains? How easy is it to DoS domain0 by draining its entropy pool? Yuk. -- Keir - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> But if sampling virtual events for randomness is really unsafe (is it
> really?) then native guests in Xen would also get bad random numbers
> and this would need to be somehow addressed.
Good point. I wonder what VMWare does in this situation.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Tuesday 09 May 2006 22:46, Roland Dreier wrote: > Keir> Where should we get our entropy from in a VM environment? > Keir> Leaving the pool empty can cause processes to hang. > > You could have something like a virtual HW RNG driver (with a frontend > and backend), which steals from the dom0 /dev/random pool. They already have a vTPM - iirc TPMs support random numbers so that could be used. But it's probably complicated to use. But if sampling virtual events for randomness is really unsafe (is it really?) then native guests in Xen would also get bad random numbers and this would need to be somehow addressed. I haven't seen real evidence yet why the virtual events should provide less randomness than the hardware. -And - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Christoph Hellwig ([EMAIL PROTECTED]) wrote: > On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote: > > The network device frontend driver allows the kernel to access network > > devices exported exported by a virtual machine containing a physical > > network device driver. > > Please don't add procfs code to new network drivers. Especially if it's > oopsable > like the code in this driver by simple device renaming. Agreed, no reason to keep the cruft around. I thought I had a comment of the sort in there. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
> The stuff in /proc could easily just be added attributes to the class_device
> kobject
> of the net device (and then show up in sysfs).
Agreed, it's on the todo list to drop proc support there. Thought that
was marked in the patch.
> > +#define GRANT_INVALID_REF 0
> > +
> > +#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
> > +#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
> > +
> > +static inline void init_skb_shinfo(struct sk_buff *skb)
> > +{
> > + atomic_set(&(skb_shinfo(skb)->dataref), 1);
> > + skb_shinfo(skb)->nr_frags = 0;
> > + skb_shinfo(skb)->frag_list = NULL;
> > +}
>
> Could you use existing sk_buff_head instead of inventing your
> own skb queue?
Hmm, there is some standard skb_queue_tail happening. I don't have a
clear idea what you mean.
> > + u8 mac[ETH_ALEN];
>
> Isn't mac address already stored in dev->dev_addr and/or dev->perm_addr?
Yes, I don't see the reason to keep in twice. It's basically a temp
buffer, but it certainly appears we can eliminate it.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
Keir> Where should we get our entropy from in a VM environment? Keir> Leaving the pool empty can cause processes to hang. You could have something like a virtual HW RNG driver (with a frontend and backend), which steals from the dom0 /dev/random pool. - R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On 9 May 2006, at 21:25, Stephen Hemminger wrote: + memcpy(netdev->dev_addr, info->mac, ETH_ALEN); + network_connect(netdev); + info->irq = bind_evtchn_to_irqhandler( + info->evtchn, netif_int, SA_SAMPLE_RANDOM, netdev->name, This doesn't look like a real random entropy source. packets arriving from another domain are easily timed. Where should we get our entropy from in a VM environment? Leaving the pool empty can cause processes to hang. -- Keir - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: > > + info->irq = bind_evtchn_to_irqhandler( > > + info->evtchn, netif_int, SA_SAMPLE_RANDOM, > > netdev->name, > > This doesn't look like a real random entropy source. packets > arriving from another domain are easily timed. Heh, given the path they take, that sadly may not be the case ;-) But point well-taken, that's easy to drop. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
> +static int setup_device(struct xenbus_device *dev, struct
> netfront_info *info) +{
> + struct netif_tx_sring *txs;
> + struct netif_rx_sring *rxs;
> + int err;
> + struct net_device *netdev = info->netdev;
> +
> + info->tx_ring_ref = GRANT_INVALID_REF;
> + info->rx_ring_ref = GRANT_INVALID_REF;
> + info->rx.sring = NULL;
> + info->tx.sring = NULL;
> + info->irq = 0;
> +
> + txs = (struct netif_tx_sring *)get_zeroed_page(GFP_KERNEL);
> + if (!txs) {
> + err = -ENOMEM;
> + xenbus_dev_fatal(dev, err, "allocating tx ring
> page");
> + goto fail;
> + }
> + rxs = (struct netif_rx_sring *)get_zeroed_page(GFP_KERNEL);
> + if (!rxs) {
> + err = -ENOMEM;
> + xenbus_dev_fatal(dev, err, "allocating rx ring
> page");
> + free_page((unsigned long)txs);
> + goto fail;
> + }
> + info->backend_state = BEST_DISCONNECTED;
> +
> + SHARED_RING_INIT(txs);
> + FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> +
> + SHARED_RING_INIT(rxs);
> + FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> +
> + err = xenbus_grant_ring(dev, virt_to_mfn(txs));
> + if (err < 0)
> + goto fail;
> + info->tx_ring_ref = err;
> +
> + err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
> + if (err < 0)
> + goto fail;
> + info->rx_ring_ref = err;
> +
> + err = xenbus_alloc_evtchn(dev, &info->evtchn);
> + if (err)
> + goto fail;
> +
> + memcpy(netdev->dev_addr, info->mac, ETH_ALEN);
> + network_connect(netdev);
> + info->irq = bind_evtchn_to_irqhandler(
> + info->evtchn, netif_int, SA_SAMPLE_RANDOM,
> netdev->name,
>
This doesn't look like a real random entropy source. packets
arriving from another domain are easily timed.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
The stuff in /proc could easily just be added attributes to the class_device
kobject
of the net device (and then show up in sysfs).
> +
> +#define GRANT_INVALID_REF0
> +
> +#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
> +#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
> +
> +static inline void init_skb_shinfo(struct sk_buff *skb)
> +{
> + atomic_set(&(skb_shinfo(skb)->dataref), 1);
> + skb_shinfo(skb)->nr_frags = 0;
> + skb_shinfo(skb)->frag_list = NULL;
> +}
> +
Could you use existing sk_buff_head instead of inventing your
own skb queue?
> +struct netfront_info
> +{
> + struct list_head list;
> + struct net_device *netdev;
> +
> + struct net_device_stats stats;
> + unsigned int tx_full;
> +
> + struct netif_tx_front_ring tx;
> + struct netif_rx_front_ring rx;
> +
> + spinlock_t tx_lock;
> + spinlock_t rx_lock;
> +
> + unsigned int handle;
> + unsigned int evtchn, irq;
> +
> + /* What is the status of our connection to the remote backend? */
> +#define BEST_CLOSED 0
> +#define BEST_DISCONNECTED 1
> +#define BEST_CONNECTED2
> + unsigned int backend_state;
> +
> + /* Is this interface open or closed (down or up)? */
> +#define UST_CLOSED0
> +#define UST_OPEN 1
> + unsigned int user_state;
> +
> + /* Receive-ring batched refills. */
> +#define RX_MIN_TARGET 8
> +#define RX_DFL_MIN_TARGET 64
> +#define RX_MAX_TARGET NET_RX_RING_SIZE
> + int rx_min_target, rx_max_target, rx_target;
> + struct sk_buff_head rx_batch;
> +
> + struct timer_list rx_refill_timer;
> +
> + /*
> + * {tx,rx}_skbs store outstanding skbuffs. The first entry in each
> + * array is an index into a chain of free entries.
> + */
> + struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1];
> + struct sk_buff *rx_skbs[NET_RX_RING_SIZE+1];
> +
> + grant_ref_t gref_tx_head;
> + grant_ref_t grant_tx_ref[NET_TX_RING_SIZE + 1];
> + grant_ref_t gref_rx_head;
> + grant_ref_t grant_rx_ref[NET_TX_RING_SIZE + 1];
> +
> + struct xenbus_device *xbdev;
> + int tx_ring_ref;
> + int rx_ring_ref;
> + u8 mac[ETH_ALEN];
Isn't mac address already stored in dev->dev_addr and/or dev->perm_addr?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote: > The network device frontend driver allows the kernel to access network > devices exported exported by a virtual machine containing a physical > network device driver. Please don't add procfs code to new network drivers. Especially if it's oopsable like the code in this driver by simple device renaming. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
On Tue, 21 Mar 2006 22:31:14 -0800 Chris Wright <[EMAIL PROTECTED]> wrote: > The network device frontend driver allows the kernel to access network > devices exported exported by a virtual machine containing a physical > network device driver. > > Signed-off-by: Ian Pratt <[EMAIL PROTECTED]> > Signed-off-by: Christian Limpach <[EMAIL PROTECTED]> > Signed-off-by: Chris Wright <[EMAIL PROTECTED]> > --- In addition to earlier comments: * should handle multiple interfaces, not just one static. * the whole notifier fake arp call back is fugly * use sysfs instead of /proc to handle the simple rxbuf_min,max stuff or use ethtool ring parameters * proc module_owner not set, so ref counting not done. Moot if you switch to sysfs. * since you add ethtool for checksum, why not some basic stuff like driver info and carrier state? * xen_net_read_mac seems like it could just be put inside driver. * minor use free_netdev() rather than kfree in error path don't bother initializing .next/.priority in notifier_block if it is just 0 * what about mtu change? * what about mac address change? * Could you support scatter gather? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
