On Mon, Mar 23, 2015 at 4:18 PM, Ian Campbell <ian.campb...@citrix.com> wrote:
> On Mon, 2015-03-23 at 15:15 +0000, Ian Campbell wrote: > > _But_ I suppose you are not really worried about the guest doing a PT > > update, but rather xenaccess playing games with the stage 2 behind the > > guest's back, which might require us to do some TLB shootdowns, and we'd > > have to assume both I-TLB and D-TLB since we don't know what the guest > > has in those pages. > > When we change the p2m we do a tlbi vmalle1is, so regardless of whether > split tlb is a thing we are flushing everything, so we should be good > from a stage 2 PoV. > When we apply p2m changes we do indeed flush the TLB. I do actually worry about a potential malicious in-guest kernel playing tricks with its pagetables which may have happened after the p2m changes were applied. The xen-access permissions are applied based on IPAs. Say I want to be notified when a specific API is being called, so I walk the guest-pagestables and set a trap at the page the IPA is one. If the malicious guest kernel wants to avoid triggering the xen-access notifications, it could theoretically prime its tables and perform the right accesses so that the iTLB still has the mapping I wanted to trap with xen-access, but the dTLB has a different mapping. The instruction abort trap will happen but in Xen I will see the mapping according to the dTLB, thus the radix-tree lookup fails and the trap is injected back into the guest. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
