do_mmu_update blindly assumes that setting the LDT will always succeed: under MMUEXT_SET_LDT: if ( ents != 0 ) percpu_info[cpu].deferred_ops |= DOP_RELOAD_LDT; further down: if ( deferred_ops & DOP_RELOAD_LDT ) (void)map_ldt_shadow_page(0); if xen thinks that one of the pages passed is mapped r/w somewhere the operation will fail: /* Map shadow page at offset @off. */ int map_ldt_shadow_page(unsigned int off) { <...> if ( unlikely(!(l1e & _PAGE_PRESENT)) || unlikely(!get_page_and_type(&frame_table[l1e >> PAGE_SHIFT], d, PGT_ldt_page)) ) return 0; <...> The user won''t know about it until he re-loads a segment register or successfully infers what operation the "Bad type" messages on the console refer to. ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net lists.sourceforge.net/lists/listinfo/xen-devel
Ian Pratt
2005-Feb-09 01:05 UTC
RE: [Xen-devel] bug in LDT error checking on stable branch
> do_mmu_update blindly assumes that setting the LDT will > always succeed:It''s deferring the operation for performance reasons, which makes it tricky to tell the guest whether it failed or not. I guess we could return an error for the whole hypercall batch, but at the point the failure is detected it would be slighty messy to report which op failed. I guess the current behaviour is a pain if you''re debugging a guest port... Ian> under MMUEXT_SET_LDT: > if ( ents != 0 ) > percpu_info[cpu].deferred_ops |= DOP_RELOAD_LDT; > > further down: > if ( deferred_ops & DOP_RELOAD_LDT ) > (void)map_ldt_shadow_page(0); > > if xen thinks that one of the pages passed is mapped r/w somewhere the > operation will fail: > /* Map shadow page at offset @off. */ > int map_ldt_shadow_page(unsigned int off) > { > <...> > > if ( unlikely(!(l1e & _PAGE_PRESENT)) || > unlikely(!get_page_and_type(&frame_table[l1e >> PAGE_SHIFT], > d, PGT_ldt_page)) ) > return 0; > > <...> > > The user won''t know about it until he re-loads a segment register or > successfully infers what operation the "Bad type" messages on the > console refer to. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive > Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at intelliview.com/go/osdn_nl > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > lists.sourceforge.net/lists/listinfo/xen-devel >------------------------------------------------------- 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. ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 9 Feb 2005, Ian Pratt wrote:> > > do_mmu_update blindly assumes that setting the LDT will > > always succeed: > > It''s deferring the operation for performance reasons, which makes it > tricky to tell the guest whether it failed or not. I guess we could > return an error for the whole hypercall batch, but at the point the > failure is detected it would be slighty messy to report which op failed. > > I guess the current behaviour is a pain if you''re debugging a guest > port...Yes. FreeBSD 5.3 added a "nice" optimization (not in 5.2.1) to a free path where it doesn''t unmap the page, leaving a dangling RW mapping. Perfectly legitimate running directly on hardware, but when the physical page got reallocated for an LDT running under xen ... So instead we hit a read fault on loading gs somewhat later - very confusing. -Kip> > Ian > > > under MMUEXT_SET_LDT: > > if ( ents != 0 ) > > percpu_info[cpu].deferred_ops |= DOP_RELOAD_LDT; > > > > further down: > > if ( deferred_ops & DOP_RELOAD_LDT ) > > (void)map_ldt_shadow_page(0); > > > > if xen thinks that one of the pages passed is mapped r/w somewhere the > > operation will fail: > > /* Map shadow page at offset @off. */ > > int map_ldt_shadow_page(unsigned int off) > > { > > <...> > > > > if ( unlikely(!(l1e & _PAGE_PRESENT)) || > > unlikely(!get_page_and_type(&frame_table[l1e >> PAGE_SHIFT], > > d, PGT_ldt_page)) ) > > return 0; > > > > <...> > > > > The user won''t know about it until he re-loads a segment register or > > successfully infers what operation the "Bad type" messages on the > > console refer to. > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IntelliVIEW -- Interactive > > Reporting > > Tool for open source databases. Create drag-&-drop reports. Save time > > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > > Download a FREE copy at intelliview.com/go/osdn_nl > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.sourceforge.net > > lists.sourceforge.net/lists/listinfo/xen-devel > > > > > ------------------------------------------------------- > 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. > ads.osdn.com/?ad_ide95&alloc_id396&opk > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > lists.sourceforge.net/lists/listinfo/xen-devel > >------------------------------------------------------- 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. ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net lists.sourceforge.net/lists/listinfo/xen-devel