On 01/10/18 12:13, Jan Beulich wrote: >>>> On 01.10.18 at 11:58, <sergey.dya...@citrix.com> wrote: >> Having the allocator return unscrubbed pages is a potential security >> concern: some domain can be given pages with memory contents of another >> domain. This may happen, for example, if a domain voluntarily releases >> its own memory (ballooning being the easiest way for doing this). > > And we've always said that in this case it's the domain's responsibility > to scrub the memory of secrets it cares about. Therefore I'm at the > very least missing some background on this change of expectations. > >> Change the allocator to always scrub the pages given to it by: >> >> 1. free_xenheap_pages() >> 2. free_domheap_pages() >> 3. online_page() >> 4. init_heap_pages() >> >> Performance testing has shown that on multi-node machines bootscrub >> vastly outperforms idle-loop scrubbing. So instead of marking all pages >> dirty initially, introduce bootscrub_done to track the completion of >> the process and eagerly scrub all allocated pages during boot. > > I'm afraid I'm somewhat lost: There still is active boot time scrubbing, > or at least I can't see how that might be skipped (other than due to > "bootscrub=0"). I was actually expecting this to change at some > point. Am I perhaps simply mis-reading this part of the description? > >> If bootscrub is disabled, then all pages will be marked as dirty right >> away and scrubbed either in idle-loop or eagerly during allocation. >> >> After this patch, alloc_heap_pages() is guaranteed to return scrubbed >> pages to a caller unless MEMF_no_scrub flag was provided. > > I also don't understand the point of this: Xen's internal allocations > have no need to come from scrubbed memory. This in particular > also puts under question the need to "eagerly scrub all allocated > pages during boot" (quoted from an earlier paragraph).
There are ways to share a Xen's page with a guest. So from a security point of view, there is no guarantee that a page allocated with alloc_xenheap_pages() will not end up accessible by some guest. -- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
