| Message ID | 455ab356-3354-1661-51d0-7f67caa9ecfb@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/mm: XSA-299 / 309 / 310 follow-up | expand |
On 20/12/2019 14:19, Jan Beulich wrote: > After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page > table") and the removal of 32-bit support the function doesn't modify > state anymore, and hence its name has been misleading. Change its name, > constify parameters and a local variable, and make it return bool. > > Also drop the call to it from mod_l3_entry(): The function explicitly > disallows 32-bit domains to modify slot 3. Furthermore, re-checking > of slot 3 when other slots change has needlessly disallowed doing this > together with making some L2 table recursively link back to an L2 used > in some L3's 3rd slot (because of the checking of the type ref count to > be 1). (Note that allowing dynamic changes of L3 entries in the way we > do is bogus anyway, as that's not how L3s behave in the native case: > They get re-evaluated only upon CR3 reloads.) I'm having a hard time following this. I agree that dropping the call from mod_l3_entry() is safe, but I cant parse the second sentence. As for the final sentence, I'm not sure that is actually true. In particular, AMD NPT says that the PDPTRs may actually behave like L3's in 4-level paging, rather than how legacy PAE used to work. > As a result of this we no longer need to play games to get at the start > of the L3 table. Leave an ASSERT() though, just in case. I'd drop the assert(). The sole caller is internal, and we would have major problems if any of mm.c operated on misaligned pointers. (I did double check all of the MM code following whichever XSA the misaligned grant map by PTE was.) > > Further move a BUG_ON() such that in the common case its condition > wouldn't need evaluating. > > Finally, since we're at it, move init_xen_pae_l2_slots() next to the > renamed function, as they really belong together (in fact > init_xen_pae_l2_slots() was [indirectly] broken out of this function). > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > We could go further here and delete the function altogether: There are > no linear mappings in a PGT_pae_xen_l2 table anymore (this was on 32-bit > only). The corresponding conditional in mod_l3_entry() could then go > away as well (or, more precisely, would need to be replaced by correct > handling of 3rd slot updates). This would mean that a 32-bit guest > functioning on new Xen may fail to work on older (possibly 32-bit) Xen. Given that PV guests can't do anything differently or they'd stop working on pre-4.14, I don't think removing this restriction is helpful. It would be worth explicitly commenting that it is a legacy restriction however. (I could have sworn I submitted a patch to do this, but I can't locate it in my tree.) > > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -1414,22 +1414,23 @@ static int promote_l1_table(struct page_ > return ret; > } > > -static int create_pae_xen_mappings(struct domain *d, l3_pgentry_t *pl3e) > +static bool pae_xen_mappings_check(const struct domain *d, > + const l3_pgentry_t *pl3e) > { > - struct page_info *page; > - l3_pgentry_t l3e3; > + const struct page_info *page; > + l3_pgentry_t l3e3; > > if ( !is_pv_32bit_domain(d) ) > - return 1; > + return true; There is now a single caller. By repositioning the caller in promote_l3_table(), this condition can be dropped, which removes one eval_nospec() from the mix (seeing as these are expensive now.) > > - pl3e = (l3_pgentry_t *)((unsigned long)pl3e & PAGE_MASK); > + ASSERT(!((unsigned long)pl3e & ~PAGE_MASK)); > > /* 3rd L3 slot contains L2 with Xen-private mappings. It *must* exist. */ > l3e3 = pl3e[3]; > if ( !(l3e_get_flags(l3e3) & _PAGE_PRESENT) ) > { > gdprintk(XENLOG_WARNING, "PAE L3 3rd slot is empty\n"); Also, by repositioning, it becomes clear that the _PAGE_PRESENT check is duplicated, and this printk() is now dead code. ~Andrew
On 20.12.2019 16:33, Andrew Cooper wrote: > On 20/12/2019 14:19, Jan Beulich wrote: >> After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page >> table") and the removal of 32-bit support the function doesn't modify >> state anymore, and hence its name has been misleading. Change its name, >> constify parameters and a local variable, and make it return bool. >> >> Also drop the call to it from mod_l3_entry(): The function explicitly >> disallows 32-bit domains to modify slot 3. Furthermore, re-checking >> of slot 3 when other slots change has needlessly disallowed doing this >> together with making some L2 table recursively link back to an L2 used >> in some L3's 3rd slot (because of the checking of the type ref count to >> be 1). (Note that allowing dynamic changes of L3 entries in the way we >> do is bogus anyway, as that's not how L3s behave in the native case: >> They get re-evaluated only upon CR3 reloads.) > > I'm having a hard time following this. I agree that dropping the call > from mod_l3_entry() is safe, but I cant parse the second sentence. > > As for the final sentence, I'm not sure that is actually true. In > particular, AMD NPT says that the PDPTRs may actually behave like L3's > in 4-level paging, rather than how legacy PAE used to work. I've re-written this to "Also drop the call to it from mod_l3_entry(): The function explicitly disallows 32-bit domains to modify slot 3. This way we also won't re-check slot 3 when a slot other than slot 3 changes. Doing so has needlessly disallowed making some L2 table recursively link back to an L2 used in some L3's 3rd slot, as we check for the type ref count to be 1. (Note that allowing dynamic changes of L3 entries in the way we do is bogus anyway, as that's not how L3s behave in the native and EPT cases: They get re-evaluated only upon CR3 reloads. NPT is different in this regard.)" If this isn't sufficiently better, then I guess I need some hint towards possible further improvements. >> As a result of this we no longer need to play games to get at the start >> of the L3 table. Leave an ASSERT() though, just in case. > > I'd drop the assert(). The sole caller is internal, and we would have > major problems if any of mm.c operated on misaligned pointers. (I did > double check all of the MM code following whichever XSA the misaligned > grant map by PTE was.) Well, okay. As said in the description it was "just in case" anyway. >> Further move a BUG_ON() such that in the common case its condition >> wouldn't need evaluating. >> >> Finally, since we're at it, move init_xen_pae_l2_slots() next to the >> renamed function, as they really belong together (in fact >> init_xen_pae_l2_slots() was [indirectly] broken out of this function). >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> We could go further here and delete the function altogether: There are >> no linear mappings in a PGT_pae_xen_l2 table anymore (this was on 32-bit >> only). The corresponding conditional in mod_l3_entry() could then go >> away as well (or, more precisely, would need to be replaced by correct >> handling of 3rd slot updates). This would mean that a 32-bit guest >> functioning on new Xen may fail to work on older (possibly 32-bit) Xen. > > Given that PV guests can't do anything differently or they'd stop > working on pre-4.14, I don't think removing this restriction is helpful. > > It would be worth explicitly commenting that it is a legacy restriction > however. (I could have sworn I submitted a patch to do this, but I > can't locate it in my tree.) I'm adding a comment to this effect. >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -1414,22 +1414,23 @@ static int promote_l1_table(struct page_ >> return ret; >> } >> >> -static int create_pae_xen_mappings(struct domain *d, l3_pgentry_t *pl3e) >> +static bool pae_xen_mappings_check(const struct domain *d, >> + const l3_pgentry_t *pl3e) >> { >> - struct page_info *page; >> - l3_pgentry_t l3e3; >> + const struct page_info *page; >> + l3_pgentry_t l3e3; >> >> if ( !is_pv_32bit_domain(d) ) >> - return 1; >> + return true; > > There is now a single caller. By repositioning the caller in > promote_l3_table(), this condition can be dropped, which removes one > eval_nospec() from the mix (seeing as these are expensive now.) I was about to say that's not possible, until I spotted the one inside the loop that it can indeed be folded with. >> - pl3e = (l3_pgentry_t *)((unsigned long)pl3e & PAGE_MASK); >> + ASSERT(!((unsigned long)pl3e & ~PAGE_MASK)); >> >> /* 3rd L3 slot contains L2 with Xen-private mappings. It *must* exist. */ >> l3e3 = pl3e[3]; >> if ( !(l3e_get_flags(l3e3) & _PAGE_PRESENT) ) >> { >> gdprintk(XENLOG_WARNING, "PAE L3 3rd slot is empty\n"); > > Also, by repositioning, it becomes clear that the _PAGE_PRESENT check is > duplicated, and this printk() is now dead code. Done as well, thanks for noticing. Jan
--- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1414,22 +1414,23 @@ static int promote_l1_table(struct page_ return ret; } -static int create_pae_xen_mappings(struct domain *d, l3_pgentry_t *pl3e) +static bool pae_xen_mappings_check(const struct domain *d, + const l3_pgentry_t *pl3e) { - struct page_info *page; - l3_pgentry_t l3e3; + const struct page_info *page; + l3_pgentry_t l3e3; if ( !is_pv_32bit_domain(d) ) - return 1; + return true; - pl3e = (l3_pgentry_t *)((unsigned long)pl3e & PAGE_MASK); + ASSERT(!((unsigned long)pl3e & ~PAGE_MASK)); /* 3rd L3 slot contains L2 with Xen-private mappings. It *must* exist. */ l3e3 = pl3e[3]; if ( !(l3e_get_flags(l3e3) & _PAGE_PRESENT) ) { gdprintk(XENLOG_WARNING, "PAE L3 3rd slot is empty\n"); - return 0; + return false; } /* @@ -1443,15 +1444,23 @@ static int create_pae_xen_mappings(struc */ page = l3e_get_page(l3e3); BUG_ON(page->u.inuse.type_info & PGT_pinned); - BUG_ON((page->u.inuse.type_info & PGT_count_mask) == 0); BUG_ON(!(page->u.inuse.type_info & PGT_pae_xen_l2)); if ( (page->u.inuse.type_info & PGT_count_mask) != 1 ) { + BUG_ON(!(page->u.inuse.type_info & PGT_count_mask)); gdprintk(XENLOG_WARNING, "PAE L3 3rd slot is shared\n"); - return 0; + return false; } - return 1; + return true; +} + +void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d) +{ + memcpy(&l2t[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)], + &compat_idle_pg_table_l2[ + l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)], + COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*l2t)); } static int promote_l2_table(struct page_info *page, unsigned long type) @@ -1621,7 +1630,7 @@ static int promote_l3_table(struct page_ pl3e[i] = adjust_guest_l3e(l3e, d); } - if ( !rc && !create_pae_xen_mappings(d, pl3e) ) + if ( !rc && !pae_xen_mappings_check(d, pl3e) ) rc = -EINVAL; if ( rc < 0 && rc != -ERESTART && rc != -EINTR ) { @@ -1663,14 +1672,6 @@ static int promote_l3_table(struct page_ unmap_domain_page(pl3e); return rc; } - -void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d) -{ - memcpy(&l2t[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)], - &compat_idle_pg_table_l2[ - l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)], - COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*l2t)); -} #endif /* CONFIG_PV */ /* @@ -2349,10 +2350,6 @@ static int mod_l3_entry(l3_pgentry_t *pl return -EFAULT; } - if ( likely(rc == 0) ) - if ( !create_pae_xen_mappings(d, pl3e) ) - BUG(); - put_page_from_l3e(ol3e, mfn, PTF_defer); return rc; }
After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page table") and the removal of 32-bit support the function doesn't modify state anymore, and hence its name has been misleading. Change its name, constify parameters and a local variable, and make it return bool. Also drop the call to it from mod_l3_entry(): The function explicitly disallows 32-bit domains to modify slot 3. Furthermore, re-checking of slot 3 when other slots change has needlessly disallowed doing this together with making some L2 table recursively link back to an L2 used in some L3's 3rd slot (because of the checking of the type ref count to be 1). (Note that allowing dynamic changes of L3 entries in the way we do is bogus anyway, as that's not how L3s behave in the native case: They get re-evaluated only upon CR3 reloads.) As a result of this we no longer need to play games to get at the start of the L3 table. Leave an ASSERT() though, just in case. Further move a BUG_ON() such that in the common case its condition wouldn't need evaluating. Finally, since we're at it, move init_xen_pae_l2_slots() next to the renamed function, as they really belong together (in fact init_xen_pae_l2_slots() was [indirectly] broken out of this function). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- We could go further here and delete the function altogether: There are no linear mappings in a PGT_pae_xen_l2 table anymore (this was on 32-bit only). The corresponding conditional in mod_l3_entry() could then go away as well (or, more precisely, would need to be replaced by correct handling of 3rd slot updates). This would mean that a 32-bit guest functioning on new Xen may fail to work on older (possibly 32-bit) Xen.