Re: [PATCH RFC 6/9] xen, libxc: Request page fault injection via libxc

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 07/03/2014 12:32 PM, Andrew Cooper wrote:
> 
> On 03/07/2014 09:23, Mihai Donțu wrote:
>> On Wednesday 02 July 2014 18:07:20 Andrew Cooper wrote:
>>> On 02/07/14 17:58, Mihai Donțu wrote:
>>>> On Wed, 2 Jul 2014 17:00:08 +0100 Andrew Cooper wrote:
>>>>> On 02/07/14 16:51, Jan Beulich wrote:
>>>>>
>>>> There were times when we wanted to get certain information from the
>>>> guest but couldn't because it was swapped out. We now handle that
>>>> situation by injecting a #PF and then let the OS respond as it would
>>>> under a normal circumstance. After the data is brought in, it traps
>>>> again into our application and we get what we need, but yes, it
>>>> requires deep knowledge about the guest OS in order to do it without
>>>> crashing it. It's doable only if you have the means necessary to
>>>> inspect its state fully, which is why some of the submitted patches
>>>> exist.
>>> What is the threat model here?
>>>
>>> It seems to me that the only safe place to organise this is from a
>>> device driver in the guest.
>> This patch by itself does not address an in-guest security issue, it
>> merely helps implement a number of guards. For example, if we want to
>> audit all attempts to write into the .text area of an application by
>> other applications (via  process_vm_writev() or equivalent) we need to
>> first bring in the complete .text sections of all modules. I forgot to
>> mention before, but this patch can be used to bring in pages from
>> memory mapped files (executables / shared objects).
>>
>> This can indeed be done in a much easier fashion directly from the
>> guest kernel, but we are envisioning a security tool that acts
>> completely from outside the domain and firmly believe that the amount
>> of work needed to do this will be worth it.
>>
> 
> Ok.  So you are looking for a way to force arbitrary pages to be paged in?
> 
> I cant see how this could ever be safe from outside the VM.  At the very
> best you will have to wait until the correct virtual address space is in
> context (which is not as easy as relying on cr3), probably wait until
> the vcpu is executing userspace code, and even then you are still
> fighting with the guest OS's paging-out algorithm.

We're waiting until vmx_vmenter_helper(). Then, we check both cs_dpl
(Jan suggested SS.DPL in an earlier reply) to make sure we're in
userspace code, and cr3:

 92 +static void check_pf_injection(void)
 93 +{
 94 +    struct vcpu *curr = current;
 95 +    struct domain *d = curr->domain;
 96 +    struct hvm_hw_cpu ctxt;
 97 +    uint32_t cs_dpl;
 98 +
 99 +    if ( !is_hvm_domain(d) || d->fault_info.virtual_address == 0 )
100 +        return;
101 +
102 +    memset(&ctxt, 0, sizeof(struct hvm_hw_cpu));
103 +    hvm_funcs.save_cpu_ctxt(curr, &ctxt);
104 +
105 +    cs_dpl = (ctxt.cs_arbytes >> 5) & 3;
106 +
107 +    if ( cs_dpl == 3 /* Guest is in user mode */
108 +         && !ctxt.pending_event
109 +         && ctxt.cr3 == d->fault_info.address_space )
110 +    {
111 +        /* Cache */
112 +        uint64_t virtual_address = d->fault_info.virtual_address;
113 +        uint32_t write_access = d->fault_info.write_access;
114 +
115 +        /* Reset */
116 +        d->fault_info.address_space = 0;
117 +        d->fault_info.virtual_address = 0;
118 +        d->fault_info.write_access = 0;
119 +
120 +        hvm_inject_page_fault((write_access << 1) | PFEC_user_mode,
121 +            virtual_address);
122 +    }
123 +}

All the hypercall itself does is set a few flags that are checked in
check_pf_injection().


Thanks,
Razvan Cojocaru

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