Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030214AbWEKJsa (ORCPT ); Thu, 11 May 2006 05:48:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030213AbWEKJsa (ORCPT ); Thu, 11 May 2006 05:48:30 -0400 Received: from ns2.suse.de ([195.135.220.15]:12737 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1030210AbWEKJs3 (ORCPT ); Thu, 11 May 2006 05:48:29 -0400 From: Andi Kleen To: Keir Fraser , tytso@mit.edu Subject: Re: [RFC PATCH 34/35] Add the Xen virtual network device driver. Date: Thu, 11 May 2006 11:47:52 +0200 User-Agent: KMail/1.9.1 Cc: Herbert Xu , xen-devel@lists.xensource.com, ian.pratt@xensource.com, rdreier@cisco.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, virtualization@lists.osdl.org, chrisw@sous-sol.org, shemminger@osdl.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605111147.53011.ak@suse.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2159 Lines: 45 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/