Xen project Mailing List

On Fri, Oct 3, 2014 at 2:37 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

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

On Thu, Oct 2, 2014 at 12:49 PM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> 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.

Yes, that's correct. That's why I said it works if you continuously monitor for writes. I think that's a reasonable assumption. We could also make the MSR write events deliver the previous value as well similar to how the CR events do it. Anyway, AFAIU the hardware traps always happen before the write so technically both approaches are pre-write from the guest's perspective.

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".

I think that's an overkill and wouldn't really get you much extra. But if its decided to be added, it sounds just fine to me.

Tamas

~Andrew

Re: [Xen-devel] Blocking CR and MSR writes via mem_access?