Blocking CR and MSR writes via mem_access?

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

Hello,

Currently hvm_memory_event_cr3() and the other hvm_memory_event_*()
functions in hvm.c can pause the VCPU and send a mem_event with the new
value of the respective register, but especially in the case of CR
events (as opposed to MSR events), this is done _after_ the value is set
(please see hvm_set_cr3() in hvm.c).

It would be interesting from a memory introspection application's point
of view to be able to receive a mem_event _before_ the value is set, and
important to be able to veto the change.

A few questions:

1. Would it be acceptable to move the CR3 event sending code so that a
mem_access client would receive the event _before_ the write takes
place? Is this likely to break other mem_event clients that might rely
on the event being received _after_ the value has been set?

2. I see that mem_event responses from all these cases (EPT violations,
CR, MSR) are handled in p2m.c's p2m_mem_access_resume() (seems to be
confirmed by testing). Is this correct?

3. What would be the sanest, most elegant way to modify Xen so that
after a mem_event reply is being received for one of these cases (CR,
MSR), the write will then be rejected? I'm asking because, as always,
ideally this would also benefit other Xen users and an elegant patch is
always more likely to find its way into mainline than a quick hack.


Thanks,
Razvan Cojocaru