From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Blocking CR and MSR writes via mem_access? Date: Fri, 3 Oct 2014 13:37:53 +0100 Message-ID: <542E98A1.5070706@citrix.com> References: <542D2DA7.1060903@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7820992457457705629==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel , Razvan Cojocaru Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============7820992457457705629== Content-Type: multipart/alternative; boundary="------------040605040909030709010609" --------------040605040909030709010609 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 03/10/14 13:32, Tamas K Lengyel wrote: > > On Thu, Oct 2, 2014 at 12:49 PM, Razvan Cojocaru > > 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 --------------040605040909030709010609 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

On 03/10/14 13:32, Tamas K Lengyel wrote:

On Thu, Oct 2, 2014 at 12:49 PM, Razvan Cojocaru <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
--------------040605040909030709010609-- --===============7820992457457705629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7820992457457705629==--