[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 2/7] arch, arm: add consistency checks to REMOVE p2m changes
On 03/25/2014 12:51 PM, Julien Grall wrote: > Hi Arianna, > > Thank you for the patch, > > On 03/25/2014 02:02 AM, Arianna Avanzini wrote: >> Currently, the REMOVE case of the switch in apply_p2m_changes() >> does not perform any consistency check on the mapping to be removed. >> More in detail, the code does not check if the guest address to be >> unmapped is actually mapped to the machine address given as a >> parameter. >> This commit attempts to add the above-described consistency check >> to the REMOVE path of apply_p2m_changes(). This is instrumental to >> one of the following commits which implements the possibility to >> trigger the removal of p2m ranges via the memory_mapping DOMCTL >> for ARM. >> >> Signed-off-by: Arianna Avanzini <avanzini.arianna@xxxxxxxxx> >> Cc: Dario Faggioli <dario.faggioli@xxxxxxxxxx> >> Cc: Paolo Valente <paolo.valente@xxxxxxxxxx> >> Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> >> Cc: Julien Grall <julien.grall@xxxxxxxxxx> >> Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> >> Cc: Jan Beulich <JBeulich@xxxxxxxx> >> Cc: Keir Fraser <keir@xxxxxxx> >> Cc: Tim Deegan <tim@xxxxxxx> >> Cc: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> >> Cc: Eric Trudeau <etrudeau@xxxxxxxxxxxx> >> Cc: Viktor Kleinik <viktor.kleinik@xxxxxxxxxxxxxxx> >> >> --- >> >> v4: >> - Remove useless and slow lookup and use already-available >> data from pte instead. >> - Correctly increment the local variable used to keep the >> machine address whose mapping is currently being removed. >> - Return with an error upon finding a mismatch between the >> actual machine address mapped to the guest address and >> the machine address passed as parameter, instead of just >> skipping the page. >> >> --- >> xen/arch/arm/p2m.c | 24 ++++++++++++++++++++---- >> 1 file changed, 20 insertions(+), 4 deletions(-) >> >> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c >> index d00c882..bb0db16 100644 >> --- a/xen/arch/arm/p2m.c >> +++ b/xen/arch/arm/p2m.c >> @@ -243,12 +243,13 @@ static int apply_p2m_changes(struct domain *d, >> int rc; >> struct p2m_domain *p2m = &d->arch.p2m; >> lpae_t *first = NULL, *second = NULL, *third = NULL; >> - paddr_t addr; >> + paddr_t addr, _maddr; >> unsigned long cur_first_page = ~0, >> cur_first_offset = ~0, >> cur_second_offset = ~0; >> unsigned long count = 0; >> unsigned int flush = 0; >> + unsigned long mfn; >> bool_t populate = (op == INSERT || op == ALLOCATE); >> lpae_t pte; >> >> @@ -258,6 +259,7 @@ static int apply_p2m_changes(struct domain *d, >> p2m_load_VTTBR(d); >> >> addr = start_gpaddr; >> + _maddr = maddr; > > You don't need a temporary variable to hold maddr and increment it. > You can directly use maddr, but you will have to remove "maddr += > PAGE_SIZE" in INSERT. > > You also need to increment maddr when first/second level are not valid. > > While reading the code, I'm wondering if we need to return an error if > we are trying to remove a non-existent page. Ian, Stefano, any thoughs? > >> while ( addr < end_gpaddr ) >> { >> if ( cur_first_page != p2m_first_level_index(addr) ) >> @@ -327,6 +329,7 @@ static int apply_p2m_changes(struct domain *d, >> >> flush |= pte.p2m.valid; >> >> + mfn = pte.p2m.base; > > I would move mfn = ... in REMOVE part because it may not be valid on > some place and wrongly used in the future. > >> /* TODO: Handle other p2m type >> * >> * It's safe to do the put_page here because page_alloc will >> @@ -335,8 +338,6 @@ static int apply_p2m_changes(struct domain *d, >> */ >> if ( pte.p2m.valid && p2m_is_foreign(pte.p2m.type) ) >> { >> - unsigned long mfn = pte.p2m.base; >> - >> ASSERT(mfn_valid(mfn)); >> put_page(mfn_to_page(mfn)); >> } >> @@ -367,9 +368,23 @@ static int apply_p2m_changes(struct domain *d, >> maddr += PAGE_SIZE; >> } >> break; >> - case RELINQUISH: >> case REMOVE: >> { >> + ASSERT(pte.p2m.valid); > > Why did you add an ASSERT here? Hmmm ... after reading you patch #4, this assert is wrong. Anyone that can call XEN_DOMCTL_memory_mapping (e.g the toolstack) can crash Xen because there is no check that the GFN has a valid mapping. You should replace this ASSERT by an if ... Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |