We are trying to set page guards in EPT entry to intercept the access to certain guest page on 32-bit hvm guest. Though we have briefly investigated into the p2m module and the ept module in xen, we only got an awkward approach that hacks into the EPT. 1. We depend on ept_set_entry to split super page into normal 4K pages first. 2. We employ the similar way that ept_set_entry has done to find an entry. Once found, we modify its access bit (rwx) violently after the p2m_type_t has applied its rules to these bits. 3. We hook the ept_handle_violation to intercept these ept violations that will cause domain crash and find out if these faults are caused by formal modifications in 2 and settle them. Then we come across several problems: We use map_domain_page to map the ept table that contains the target entry. After changing the access bits in that entry, we use unmap_domain_page to activate the modification. But it seems that when we again map the ept table and fetch the exact entry we''ve modified just before, our modifications haven''t taken effect. Any sometimes the modification will cause interception while in some cases it doesn''. Is there anything to do which our using of map/unmap functions? Or do we need to flush something when we have made the modifications? -- Kenmark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 03:00 +0000 on 03 Feb (1265166046), ken mark wrote:> We use map_domain_page to map the ept table that contains the target > entry. After changing the access bits in that entry, we use > unmap_domain_page to activate the modification.unmap_domain_page() won''t "activate" anything; it just indicates that you''re done with the mapping. On 64-bit Xen it''s a no-op.> But it seems that when we again map the ept table and fetch the exact > entry we''ve modified just before, our modifications haven''t taken > effect.Sorry to ask the obvious questions, but: - Are you sure you''re mapping the right entry? Is it the same MFN both times? - Have you tried tracking all other mappings of the same page to see if it''s put back in between? - Are you running a multiprocessor system? Do you hve sufficient locking around the operation to stop confusion from simultaneous changes on other CPUs? The EPT code has historically been lacking in this area.> Any sometimes the modification will cause interception while in some > cases it doesn''. Is there anything to do which our using of map/unmap > functions? Or do we need to flush something when we have made the > modifications?Yes, you need to flush the EPT entries from TLBs before changes will take place. You need to call hvm_flush_guest_tlbs() on every CPU in the guest''s domain_dirty_cpumask. Xen''s normal flush_tlb_mask() operation does this as a side-effect. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks for your inspiring explanation. We''ve searched the source code for the map/unmap implementation on 32-bit and 64-bit Xen and get a better understanding. Based on the map/unmap usage, we''ve guessed that the problem has much to do our ways of finding and updating the entry, though it turns out to be the same each time. And thank you for your reminding me of those important facts that may lead to the problem. We''ll try to fix it in a few days and come back for more useful advice from you. 2010/2/3 Tim Deegan <Tim.Deegan@citrix.com>> Hi, > > At 03:00 +0000 on 03 Feb (1265166046), ken mark wrote: > > We use map_domain_page to map the ept table that contains the target > > entry. After changing the access bits in that entry, we use > > unmap_domain_page to activate the modification. > > unmap_domain_page() won''t "activate" anything; it just indicates that > you''re done with the mapping. On 64-bit Xen it''s a no-op. > > > But it seems that when we again map the ept table and fetch the exact > > entry we''ve modified just before, our modifications haven''t taken > > effect. > > Sorry to ask the obvious questions, but: > - Are you sure you''re mapping the right entry? Is it the same MFN > both times? > - Have you tried tracking all other mappings of the same page to see if > it''s put back in between? > - Are you running a multiprocessor system? Do you hve sufficient locking > around the operation to stop confusion from simultaneous changes on > other CPUs? The EPT code has historically been lacking in this area. > > > Any sometimes the modification will cause interception while in some > > cases it doesn''. Is there anything to do which our using of map/unmap > > functions? Or do we need to flush something when we have made the > > modifications? > > Yes, you need to flush the EPT entries from TLBs before changes will > take place. You need to call hvm_flush_guest_tlbs() on every CPU in the > guest''s domain_dirty_cpumask. Xen''s normal flush_tlb_mask() operation > does this as a side-effect. > > Cheers, > > Tim. > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] >-- Kenmark _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel