On 01/10/18 14:57, Boris Ostrovsky wrote:
> 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.

There is no regression.  How Xen handles its free memory is unrelated to
how the guest handles its free memory, and real usecases exist (AMD SEV
most obviously) where there deliberately isn't full trust between the
guest and the hypervisor.

It is suboptimal in the case where Xen and the guest mutually trust each
other, but that isn't the only case which exists.

~Andrew

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

Reply via email to