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.
You were on the call when this was discussed, along with the synchronous scrubbing in destroydomain. Put simply, the current behaviour is not good enough for a number of security sensitive usecases. The main reason however for doing this is the optimisations it enables, and in particular, not double scrubbing most of our pages. > >> 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? No. Sergey tried that, and found a massive perf difference between scrubbing in the idle loop and scrubbing at boot. (1.2s vs 40s iirc) Scrubbing at boot has some deliberate optimisations to reduce the pressure on the heap lock, and I expect that is where the performance difference lies. It is an issue which wants looking into irrespective of other changes. > >> 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 isn't true. Almost every caller re-zeroes an allocated page which is the cause of the double scrubbing in most cases. By having the allocators guarantee to hand out zeroed pages, we can avoid the redundant scrubbing. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
