>>> On 18.12.15 at 07:29, <kevin.t...@intel.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Wednesday, December 16, 2015 3:58 PM >> >> ... since we don't need its virtual address anywhere (it's a >> placeholder page only after all). For this wo work (and possibly be >> done elsewhere too) share_xen_page_with_guest() needs to mark pages >> handed to it as Xen heap ones. >> >> To be on the safe side, also explicitly clear the page (not having done >> so was okay due to the XSA-100 fix, but is still a latent bug since we >> don't formally guarantee allocations to come out zeroed, and in fact >> this property may disappear again as soon as the asynchronous runtime >> scrubbing patches arrive). > > Do you mean that asynchronous scrubbing may scrub page after they > are re-allocated? It's unrelated but a bit risky to me.
No, the issue would have been exposure of hypervisor or foreign VM data, i.e. an information leak. >> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> --- >> Alternatives might be to use a >> - global (or perhaps per-node) page across VMs (on the basis that VMs >> shouldn't be writing into that page anyway) >> - fake MFN pointing into nowhere (would need to ensure no side effects >> can occur, like PCIe errors or NMIs) > > one page per VM should be fine. We don't need go that route. > > the patch overall looks OK to me: Except that it's broken - it turns out that I only thought I've tested this, while in fact I had tested a stale binary. v2 on its way. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
