Re: [Xen-devel] [PATCH 08/11] x86/altp2m: add remaining support routines.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.15 at 18:17, <edmund.h.white@xxxxxxxxx> wrote:
> On 01/16/2015 12:24 AM, Jan Beulich wrote:
>>>>> On 15.01.15 at 22:00, <edmund.h.white@xxxxxxxxx> wrote:
>>> On 01/15/2015 09:33 AM, Tim Deegan wrote:
>>>> Hi,
>>>>
>>>> Sorry for the fractured replies - my notes are confused about which
>>>> functions were defined where.
>>>>
>>>> At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
>>>>> +bool_t p2m_change_altp2m_pfn(struct domain *d, uint16_t idx,
>>>>> +                             unsigned long old_pfn, unsigned long 
>>>>> new_pfn)
>>>>> +{
>>>> [...]
>>>>> +    mfn = ap2m->get_entry(ap2m, new_pfn, &t, &a, 0, NULL);
>>>>> +
>>>>> +    if ( !mfn_valid(mfn) )
>>>>> +        mfn = hp2m->get_entry(hp2m, new_pfn, &t, &a, 0, NULL);
>>>>> +
>>>>> +    if ( !mfn_valid(mfn) || !(t == p2m_ram_rw || t == p2m_ram_rw) )
>>>>> +        goto out;
>>>>> +
>>>>> +    /* Use special ram type to enable #VE if setting for current domain 
>>>>> */
>>>>> +    if ( current->domain == d )
>>>>> +        t = p2m_ram_rw_ve;
>>>>> +
>>>>> +    if ( !ap2m->set_entry(ap2m, old_pfn, mfn, PAGE_ORDER_4K, t, a) )
>>>>> +        rc = 1;
>>>>
>>>> I'm afraid this is Terribly Unsafe[tm].  Following on from my point on
>>>> the log-dirty patch, if the original gfn gets removed from the guest,
>>>> for any reason, we need a way to find and remove this mapping too.
>>>>
>>>> That will be non-trivial, since you can't do it by exhaustive search.
>>>> Maybe some sort of reverse mapping?
>>>
>>> How often is it likely that a page will be removed? If it's
>>> infrequent, maybe an exhaustive search will suffice. I don't
>>> expect there to be anywhere near 10 alternates in use in most
>>> cases, and they are sparsely populated.
>> 
>> A fundamental thing you need to keep in mind when considering
>> exhaustive searches is that these need to be preemptible, no
>> matter how infrequent they are. Which may be difficult to
>> arrange for, based on experience with code where we needed
>> to add such preemption later on (as security fixes).
> 
> I've seen plenty of activity on the list regarding pre-emptible
> hypercalls, but I'm not clear what level of DOS this prevents. Is
> it to guard against a DOS against a domain, or against the whole system?

The hypervisor itself is not preemptible. Hence any code running
for long enough without allowing softirqs to be processed put the
system as a whole at risk. Furthermore, anything not allowing
events to be processed inside the calling guest for an extended
period of time is going to put the guest at risk (and again the whole
system if that guest is the hardware or control domain).

Jan


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