Re: [Xen-devel] [PATCH V2] mem_event: Allow emulating an instruction that caused a page fault

[Tim Deegan <tim@xxxxxxx>]

At 01:13 +0200 on 22 Jan (1358817224), Razvan Cojocaru wrote:
> Hello,
> 
> > Tim's point is that you won't get all the mem events, because the 
> > instruction can easily touch multiple pages. It's a question that addresses 
> > the need for this patch in the first place.
> 
> what would be an example of such an instruction?

x86 instructions aren't aligned, so any instruction that encodes as more
than one byte can touch two pages just in instruction fetch, if it
overlaps the end of a page.  The same goes for explicit memory operands,
so an instruction like MOVSW that has two memory operands can touch six
pages - two for the instruction fetch and two for each operand. 

Each of those accesses is to a virtual address; in 64-bit mode a TLB
miss can add four more memory accesses to walk the pagetables, so we're
looking at a worst case of 25 pages of memory that might be
touched by a successful MOVSW (the top-level pagetable only counts once).

But what if the last access caused a page fault?  After up to 24
accesses, the CPU now needs to access the IDT to figure out what to do
with #PF (+4 = 28), and the stack to push an exception (+8 = 36), and if
the OS is using a task gate then it needs the old and new TSSes (+8 =
44).  And if the stack faults, we nede to do the whole thing again for
#DF (-1, +12 = 55).  Now that's a pretty unlikely scenario (and I may
have got some of the details wrong) but the upshot is: a single x86
instruction can access enormous amounts of memory, so turning off
protection and single-stepping, especially if you don't trust the OS, is
exposing a lot more than the single frame you took the first fault on.

Cheers,

Tim.



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