Re: Blocking CR and MSR writes via mem_access?

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 10/02/14 14:39, Jan Beulich wrote:
>>>> On 02.10.14 at 12:49, <rcojocaru@bitdefender.com> wrote:
>> 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.
> 
> So what do you expect the effect of denying the write to be?
> Wouldn't crashing the guest explicitly have about the same effect?

Thanks for the quick reply!

Denying a normal, legitimate write, would indeed be a problem along the
lines of what you are describing, but the point would be to block
malicious writes that would modify the SYSCALL entry point, disable SMAP
/ SMEP, and so on.

>> 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?
> 
> I don't think you should break existing behavior. If you need an
> event before the setting gets carried out, just add another one.

Understood.


Thanks,
Razvan Cojocaru