PoD is supposed to be entirely transparent to guest, but this interface has
been left exposed for a long time.
The use of PoD requires careful co-ordination by the toolstack with the
XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning target. The
best a guest can do without toolstack cooperation crash.
Furthermore, there are combinations of features (e.g. c/s c63868ff "libxl:
disallow PCI device assignment for HVM guest when PoD is enabled") which a
toolstack might wish to explicitly prohibit (in this case, because the two
simply don't function in combination). In such cases, the guest mustn't be
able to subvert the configuration chosen by the toolstack.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Jan Beulich <jbeul...@suse.com>
CC: George Dunlap <george.dun...@eu.citrix.com>
---
xen/common/memory.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 1ead35c..ccb9207 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -903,7 +903,16 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
if ( op == XENMEM_populate_physmap
&& (reservation.mem_flags & XENMEMF_populate_on_demand) )
+ {
+ /* Disallow populating PoD pages on oneself. */
+ if ( d == curr_d )
+ {
+ rcu_unlock_domain(d);
+ return start_extent;
+ }
+
args.memflags |= MEMF_populate_on_demand;
+ }
if ( xsm_memory_adjust_reservation(XSM_TARGET, curr_d, d) )
{
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
