Re: [Xen-devel] [PATCH v3] xen/arm: p2m: Correctly flush TLB in create_p2m_entries

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-01-14 at 14:44 +0000, Ian Campbell wrote:
> On Tue, 2014-01-14 at 13:36 +0000, Julien Grall wrote:
> > The p2m is shared between VCPUs for each domain. Currently Xen only flush
> > TLB on the local PCPU. This could result to mismatch between the mapping in 
> > the
> > p2m and TLBs.
> > 
> > Flush TLB entries used by this domain on every PCPU. The flush can also be
> > moved out of the loop because:
> >     - ALLOCATE: only called for dom0 RAM allocation, so the flush is never 
> > called
> >     - INSERT: if valid = 1 that would means with have replaced a
> >     page that already belongs to the domain. A VCPU can write on the wrong 
> > page.
> >     This can happen for dom0 with the 1:1 mapping because the mapping is not
> >     removed from the p2m.
> >     - REMOVE: except for grant-table (replace_grant_host_mapping), each
> >     call to guest_physmap_remove_page are protected by the callers via a
> >         get_page -> .... -> guest_physmap_remove_page -> ... -> put_page. So
> >     the page can't be allocated for another domain until the last put_page.
> >     - RELINQUISH : the domain is not running anymore so we don't care...
> > 
> > Also avoid leaking a foreign page if the function is INSERTed a new mapping
> > on top of foreign mapping.
> > 
> > Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> 
> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> 
> Release hat: There are two major issues here, one is not broadcasting
> the TLB flush, which is a potential security issue (another VCPU can
> keep accessing a page after it is freed). The other is a potential DoS
> by leaking a reference on a foreign page, which would stop that domain
> from ever being destroyed.
> 
> Either of these two issues would be enough to justify taking this change
> for 4.4.
> 
> We are cutting rc2 at the moment, I will apply after that is out the
> way.

Done, on top of "xen/arm: correct flush_tlb_mask behaviour".


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel