Re: [Xen-devel] [PATCH] mm/page_alloc: always scrub pages given to the allocator

[Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>]

On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > On 01.10.18 at 15:12, <andrew.cooper3@xxxxxxxxxx> wrote:
> > 
> > On 01/10/18 12:13, Jan Beulich wrote:
> > > > > > On 01.10.18 at 11:58, <sergey.dyasli@xxxxxxxxxx> 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.
> 
> Quite possible, but it has been a while.
> 
> > Put simply, the current behaviour is not good enough for a number of
> > security sensitive usecases.
> 
> Well, I'm looking forward for Sergey to expand on this in the commit
> message.

Jan,

I think this is the main argument here: what to do about those security
sensitive use cases? Scrubbing everything unconditionally might be a too
radical approach. Would inroducing a new cmdline param be appropriate?

> 
> > The main reason however for doing this is the optimisations it enables,
> > and in particular, not double scrubbing most of our pages.
> 
> Well, wait - scrubbing != zeroing (taking into account also what you
> say further down).

Andrew,

I'm not yet convinced myself about the value that returning always zeroed
pages from the allocator provides. Most of the pages are given to guests
anyway, and re-zeroing a few pages in the hypervisor doesn't sound
too bad. But maybe I'm just not aware of cases where Xen performs large
allocations and zeroes them afterwards?

-- 
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel