WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen memory management

To: Srujan Kotikela <ksrujandas@xxxxxxxxx>
Subject: Re: [Xen-devel] Xen memory management
From: David Xu <davidxu06@xxxxxxxxx>
Date: Fri, 24 Jun 2011 11:28:39 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jonathan Tripathy <jonnyt@xxxxxxxxxxx>
Delivery-date: Fri, 24 Jun 2011 08:29:16 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ip96oSBtvys1sGMaHovH3gGbTUIP4ymwRfUEvmO7GbI=; b=cFvHqXqKZimv2mYYNTGansHDBY4Ia1k4W4KshxpglJCi1rrkJr1huwNA2Lrg+JaVen uiLm0khgbThxAR7Kh/QCcgev2CvLdlXJxi8JPfHEmrDo/XWU778+aMcvp1N6Yc98nChd 6S7Ho6irGvozXVuCjo3D/xgXqreB0LhpBXOSY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fZZn1mju+pNHcgoAeul9r2MeZ/TRRAkKnIBFqWpsL2tENf2b1Ml5iAULLX/Hl2ef/o l6o7qWBm3d9gJn0UZPdLaIwprHkIfFu+iqihUIv3w9WZXWLYs/RPWhTVkC9OGKCIHCBC oVn9HVkfl4TEqLQOrJIClWJgiGSCTBsEmNyI4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTikBVc79v2ERQCXFBzPPdG6qMA=jrg@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BANLkTinmK9UogogAk0kn6qzNS12BXmfbLQ@xxxxxxxxxxxxxx> <20110623092711.GU17634@xxxxxxxxxxxxxxxxxxxxxxx> <BANLkTi=WzAQ5dugc4Gwm1-5pStcGCt0SpQ@xxxxxxxxxxxxxx> <4E03BA38.6060003@xxxxxxxxxxx> <BANLkTikm5Q8DNHr1VTwO6zmZL_e_Xnea+g@xxxxxxxxxxxxxx> <4E03D772.8080508@xxxxxxxxxxx> <BANLkTi=Y8iRM+eN9LsP7+OevcDX+ZVXAEg@xxxxxxxxxxxxxx> <BANLkTikBVc79v2ERQCXFBzPPdG6qMA=jrg@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

I've read that paper you sent to me before, and the paper I am reading now is truly related to that paper. The difference is that one is to create covert  channels between cooperating processes running in different VMs, the other is to infer something important of a victim VM from a attacking VM according to detected cache activity.  However the paper I am reading does not tell me how to trace the owner of the detected cache activity. Usually, there are many VMs on one cloud server. And the vCPUs of those VMs are frequently migrating among pCPUs. So the VM which shares LLC with the attacking VM is indeterminate. I think only detecting some cache activity without knowing its owner is not powerful.

Thanks,
Cong

2011/6/24 Srujan Kotikela <ksrujandas@xxxxxxxxx>

On Thu, Jun 23, 2011 at 8:37 PM, David Xu <davidxu06@xxxxxxxxx> wrote:
 On a shared-memory system with multi-core cpu, can one VM occupy all cache and prevent other VMs using cache efficiently?

Thanks for reply from all of you. I am reading a paper which tells some secure problem of Xen VMM. I am not familiar with something that is related to those problems. So I really need your help. Of course, please feel free to post your opinion. Anybody is welcome to have a discuss.


2011/6/23 Jonathan Tripathy <jonnyt@xxxxxxxxxxx>

On 24/06/2011 00:50, David Xu wrote:

2011/6/23 Jonathan Tripathy <jonnyt@xxxxxxxxxxx>

On 23/06/2011 23:08, David Xu wrote:
Thanks. My concern is that if several VMs are mapped to same memory, one VM may get something from the memory which has ever been used by another VM. This may cause some secure problems. 



Someone correct me if I'm wrong, but I'm pretty sure that a DomU kernel (If the flag is set correctly during compile time) will scrub (i.e. "zero") RAM first before releasing it to the Xen Hypervisor. Then hypervisor will then subsequently assign that bit of RAM to another domain.

Sounds good. Does Xen VMM can control the mapping between a part of memory and cache line? That is to say I wander whether Xen can guarantee different VMs will use different cache line. Thanks.

Regards,
Cong

Please don't top post :)

I'm not a Xen dev, so it would be great if a dev could let me know if I'm talking rubbish or not. However from my very limited knowledge of how CPU caches work (which comes from basic single CPU, non VMM related system), common sense would tell me that the cache line would be different for each DomU, as a CPUs cache is inherently linked to main memory (RAM). I believe that the process used to access data from memory is abstracted by the CPU, so assuming that Xen prevents access to RAM from another DomU, I guess it would make sense to say that any data that is cached in the CPU is protected.

Then again, I could be completly wrong......



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


Have a look at this:


_SDK

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel