| |
|
 |
|
 |
|
|
|
| |
|
|
xense-devel
Re: [Xense-devel] Xen memory management
> > 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 mapping
It'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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
|
|
| |
|
Home