From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ed White Subject: Re: [PATCH 08/11] x86/altp2m: add remaining support routines. Date: Fri, 16 Jan 2015 09:17:32 -0800 Message-ID: <54B947AC.2020302@intel.com> References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com> <1420838801-11704-9-git-send-email-edmund.h.white@intel.com> <20150115173357.GK57240@deinos.phlegethon.org> <54B82A80.2000709@intel.com> <54B8D8E20200007800055B18@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B8D8E20200007800055B18@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, Tim Deegan , ian.jackson@eu.citrix.com, ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 01/16/2015 12:24 AM, Jan Beulich wrote: >>>> On 15.01.15 at 22:00, 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