From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: Blocking CR and MSR writes via mem_access? Date: Fri, 03 Oct 2014 15:42:30 +0300 Message-ID: <542E99B6.2090100@bitdefender.com> References: <542D2DA7.1060903@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 10/03/14 15: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. Hello Tamas, thanks for the reply! I was hoping to hear from a fellow mem_event user. :) Noted, as per your (and Jan's) suggestion, I won't touch the existing CR events. > 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. Indeed, thanks for the idea! I was thinking doing that (rather than than just rejecting a pre-write event) might impact performance, but for one your solution is more elegant (doesn't duplicate CR events), and I don't think there would be many instances of when the value needs to be changed back anyway. Thanks, Razvan Cojocaru