On 10/1/18 9:50 AM, George Dunlap wrote: > On 10/01/2018 02:44 PM, Boris Ostrovsky wrote: >> On 10/1/18 9:12 AM, Andrew Cooper wrote: >>> 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. >> OTOH, it introduces double scrubbing for ballooning because (at least >> Linux) guests do scrub memory before handing it back to the hypervisor. > We could add a Xen feature flag which tells the guest balloon driver > whether the hypervisor will scrub pages (and thus it doesn't need to).
We can, but we are regressing existing guests. Can we except ballooned pages from being scrubbed, and instead have a guest request scrubbing if it has concerns (that Andrew mentioned) about this? -boris > > Andy, wasn't unconditional scrubbing of guest pages also required by > some certification or other? > > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
