[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen memory management
Hi, At 21:37 -0400 on 23 Jun (1308865026), David Xu wrote: > On a shared-memory system with multi-core cpu, can one VM occupy all cache > and prevent other VMs using cache efficiently? *Please* don't top-post. Xen currently has no mechanism to enforce fair use of the cache, though its coarse-grained scheduling might help a bit. Likewise there's no explicit defence against side-channel attacks based on cache timing. I suspect both attacks are probably harder in a VMM than an OS, because it's hard to know when or where your target VCPU is running, but I've seen enough clever exploits not to claim it can't be done! > Thanks for reply from all of you. I am reading a paper which tells some > secure problem of Xen VMM. Can you share it with us, maybe? Vulnerability reports are encouraged, to the security@xxxxxxx email address. Our draft disclosure process is here: http://lists.xensource.com/archives/html/xen-devel/2011-05/msg01591.html > >> 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. General VM memory is only shared - with privileged VMs (i.e. dom0); - with per-VM device-emulation VMs (which effectively live inside the VM's protection space) so they can emulate DMA; and - with other VMs as specified by the owning VM's ACL (grant tables). Memory that is freed by a guest (e.g. when ballooning) must be scrubbed by the guest before returning it. The exception is domain destruction, when the memory of the dead domain is scrubbed by Xen. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xxxxxxxxxx> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |