Re: Blocking CR and MSR writes via mem_access?

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2410 bytes --]

On 03/10/14 13:32, Tamas K Lengyel wrote:
>
> On Thu, Oct 2, 2014 at 12:49 PM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>
>     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?
>
>  
> Yes, it would break existing applications.
>  
>
>     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.
>
>
> You can already block such writes with the existing post-write event
> delivery. If you are continuously watching for writes, you know what
> the previous value was (for CR events it is actually delivered to you
> by Xen as well as per my recent patch). If you don't like a particular
> new value that was set, just reset it to the value you had / want.
>
> Tamas

That doesn't work if you join an event listener between the previous MSR
write and one you wish to veto.

Having a "pre-write" event hook which the listener can register for
(instead of the post-write hook) sounds like a plausible plan, where the
result of the event can be Yes/No/"Do this in stead".

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 4355 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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