| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: Xen Security meeting summary
> > How does letting an attacker know the physical to machine mappings
> > benefit an attacker? I assume the attacker still would not have
> > read/write access to pages that do not belong to the compromised
> > domain. Is there a concrete attack that people are aware of, or is
> > this just a precautionary measure?
>
> The concern here was that we not give an attacker any more information
> than necessary for the proper functioning of the system.
>
> As you correctly noted, each domain's pages are protected
> from access by
> other domains (modulo a small number of shared pages).
> However, should
> there be a bug in this protection that did allow some unauthorized
> cross-domain access, knowing the physical pages used by other domains
> would increase the capabilities of an attacker (over random page
> scribbling).
It's hard to see how knowing pfns would help an attacker. If a guest
randomizied its free list at start of day would it would confuse any
attempt to track down particular user space pages. Doing the same for
kernel pages is harder but certainly possible if anyone cared.
> And though it wasn't the motivation for the concern, removing such
> global visibility also has the benefit of limiting one type of covert
> channel.
>
> So the thinking was that if we could remove these other
> domain mappings
> without significant changes or disruptions then it is beneficial to do
> so.
The trouble is, it's not. We experimeted with having each guest maintain
its own private machine_to_phys table using AVL trees, but there was a
measurable performance hit. Of course, its possible to run Xen in
shadow page table mode rather than use the normal paravirtualized
direct-mode pagetables. This avoids the p2m table in the guest
altogether, but you have to take the (not insignificant) time and space
hit associated with shadow pagetables.
We decided that the shared m2p table was a good soloution, but it is a
potential covert channel. However, in a system with multiple domains
using the same memory hierarchy you've got some *huge* bandwidth covert
channels anyhow...
Ian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home