[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 10/02/14 14:51, Jan Beulich wrote:
>>>> On 02.10.14 at 13:46, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 10/02/14 14:39, Jan Beulich wrote:
>>>>>> On 02.10.14 at 12:49, <rcojocaru@xxxxxxxxxxxxxxx> 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.
> 
> I'd be really curious to know how you envision telling a malicious from
> a legitimate operation here.

As part of the security logic, SMEP / SMAP shouldn't be disabled and the
SYSCALL entry point should not be modified. PatchGuard watches for this,
but when it is somehow compromised, or otherwise unavailable, the guest
would still be protected.


Thanks,
Razvan Cojocaru

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.