Thank you for bringing this topic up Myong. Thanks Mark for explaining the M2P mapping. xense-devel-bounces@lists.xensource.com wrote on 02/16/2006 09:27:36 AM:> > Xen interface manual describes the following: > > "Xen maintains a globally readable machine-to-physical table which > > records the mapping from machine page frames to pseudo-physical ones." > ... > It''s mapped into a domain''s address space. (nb. this is x86 specific).I> can''t remember where it''s mapped, though... Anyhow, the overhead of a > hypercall isn''t necessary to read it, it''s just a single memory access. > > The advantage here is that a domain can map a machine address back intoa> guest physical address by simply doing a table lookup. This also meansit> can see the M2P mappings for all the other domains,...> but this doesn''t really > leak any information since it still can''t see the memory contents ofother> domains.The sentence above seems optimistic. To determine how much a domain can leak through this shared table is an interesting problem. I have two questions related to this problem: a) How easily can a domain affect its own M2P mapping? --> this gives a first estimate about how easily a domain can modulate information onto the mapping, which can be observed by other domains looking at this mapping b) Can this global mapping be converted to a per-domain mapping so that a domain can only access its own M2P mappings? (Is there any reason why one domain would need to see another domain''s mapping?) Note: there are non-Xen specific implicit/covert/illegal channels based on shared HW/SW resources. While this is not a Xen-specific problem, Xen as an open-source VMM offers a great foundation for researchers to apply existing and cooperatively develop new covert channel analysis technology and tools. Finding covert channels is one thing, estimating their real channel bandwidth is as important.> It is, however, a channel by which malicious guests might theoretically > exchange data whilst bypassing security checks.Yes. It is up to security researchers to bring this "theoretically" into a "real" context before selling solutions to users/customers. Very hard problem.>This is only reallyan issue > in Mandatory Access Control systems, and even there there are liable tobe> many other covert channels too.The question that might arise in the future is where to start restricting covert channels and how to balance the trade-off between security and performance/code intrusiveness of security configurations. To find a trade-off, we need bandwidth estimates for covert channels, which likely depend on the VMM configuration (noise on this covert channel can depend on how many VMs are running, what kind of resource control is applied, etc.). Are covert channel analysis tools available that apply to the C language and the programming environment of Xen? The Chinese Wall policy available in the Xen Access Control Module offers a first trade-off between security and utilization (risk mitigation): it supervises which VMs can run at the same time on the same system. In doing so, it controls the VMs among which the hardware resources and hypervisor resources are shared.> > Is it possible to read memory content of guest domain B (or domain 0)from> > guest domain A? > > No. On x86 you can only read memory if you can map it with thepagetables> (i.e. no direct physical addressing). You can therefore only read thememory> contents of another domain if you can create a pagetable mapping forthat> domain. Xen validates any updates to the pagetables to make sure thatthey> are safe, so a domain can''t create arbitrary mappings to other domains -if> it tries to make an illegal mapping, Xen won''t allow the pagetableupdates. Thanks Reiner _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
> > but this doesn''t really > > leak any information since it still can''t see the memory contents of > > other > > > domains. > > The sentence above seems optimistic. To determine how much a domain can > leak through this shared table is an interesting problem.Yep. It doesn''t leak any security-related information just by being there, but it could certainly be used as a signalling channel.> a) How easily can a domain affect its own M2P mapping? > --> this gives a first estimate about how easily a domain can modulate > information onto the mapping, > which can be observed by other domains looking at this mappingIt''s updated using a hypercall - the hypercall could of course be rate-limited but this might impact performance. I''m not sure that doing this would affect performance much in most cases, but it''d have an impact on network IO.> b) Can this global mapping be converted to a per-domain mapping so that a > domain can only access its own M2P mappings? > (Is there any reason why one domain would need to see another domain''s > mapping?)Full details in my other e-mail... Essentially there''s no benefit to being able to see another domains mappings, but maintaining a per-domain M2P would imply a substantial extra space usage. Less-flexible memory allocation could be used to limit the necessary size of the M2P (i.e. allocate in larger chunks, instead of a per-page basis), I guess, but this would require changes to the IO model to work well (consider page flipping).> Note: there are non-Xen specific implicit/covert/illegal channels based on > shared HW/SW resources. While this is not a Xen-specific problem, Xen as > an open-source VMM offers a great foundation for researchers to apply > existing and cooperatively develop new covert channel analysis technology > and tools. Finding covert channels is one thing, estimating their real > channel bandwidth is as important.*nod*> The question that might arise in the future is where to start restricting > covert channels and how to balance the trade-off between security and > performance/code intrusiveness of security configurations. To find a > trade-off, we need bandwidth estimates for covert channels, which likely > depend on the VMM configuration (noise on this covert channel can depend > on how many VMs are running, what kind of resource control is applied, > etc.). > > Are covert channel analysis tools available that apply to the C language > and the programming environment of Xen?I guess a straightforward way might just be to write code to exploit these covert channels? It''d certainly be quite interesting and would give a concrete measure of bandwidth (nb. an analysis of covert channels and their bandwidth in one or more modern enterprise-class VMMs would make an interesting paper!) There''s probably a surprisingly large set of possible covert channels - particularly once you consider dom0. Cheers, Mark> The Chinese Wall policy available in the Xen Access Control Module offers > a first trade-off between security and utilization (risk mitigation): it > supervises which VMs can run at the same time on the same system. In doing > so, it controls the VMs among which the hardware resources and hypervisor > resources are shared. > > > > Is it possible to read memory content of guest domain B (or domain 0) > > from > > > > guest domain A? > > > > No. On x86 you can only read memory if you can map it with the > > pagetables > > > (i.e. no direct physical addressing). You can therefore only read the > > memory > > > contents of another domain if you can create a pagetable mapping for > > that > > > domain. Xen validates any updates to the pagetables to make sure that > > they > > > are safe, so a domain can''t create arbitrary mappings to other domains - > > if > > > it tries to make an illegal mapping, Xen won''t allow the pagetable > > updates. > > Thanks > Reiner-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel