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

[Ed White <edmund.h.white@intel.com>]

On 01/16/2015 12:24 AM, Jan Beulich wrote:
>>>> On 15.01.15 at 22:00, <edmund.h.white@intel.com> 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?

Ed