[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 1/2] x86/mm: XENMEM_{get,set}_pod_target are restricted to HVM domains

  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Sep 2021 10:54:42 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jo8bPyvtaH5xAEf64N9SfjM0M/xdcPBEVhdBoKC14/8=; b=JZ3SNtuADJq5bN5mFseYKVb7hDcDHDCNTqQ+Y8VFqOyTCbSmhIb/nYRGndZJZvXDYNtk3KUKvlE/+53X+pnUjCHr9+WGsLIEB4nP+b3OORi32TV3lx19Md7Zgcb71dya/owQD4Lhp/B5mdAxIeNrAA5OxdiliXy74Pynb5myzAfUTMS72N5XLR36LbqQFT84kI8FfGwG22FQbkSGe7ar2HgqNAs1y1g+ix8UsFV5G/zXFIX5Ozvzt8/r+eDN5eHrr2ucrauhmyuFBO7e5H640U32iLQFDttYhFC3tvbkCvj7hhI2HVUNoKJkV4I0M3owvbjFohN16gfL9E35Koedjg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KSSAl6ffjBSou5yA57i1XjPffkOEI7u22DmOif7SKyYez3DlwqJ0vtbdO3wi3xcQGfORK1h7AUMvHo6ADAORfHSiASxviK67TiqItw/L58kmiWV7jsCJ1+1Tcnzbym86JIqdyGvxNPEPUofhtIpzbgb/BNlCP+Q1uF996sKZzrTYZnYsWJ4JN6bnjSXYZ7nsjQOLR8zgNgaJxKZdYWMTOHf1MC4Ec16+BUU+dlAwi5acN1uL8Vy0oFpX8HJFUF/xQ2rZnYMCn5huaBzP7X2t1//FQeQPWzDQ2AXQAkgOGgrZTl4NdeO8QQWBHL0Sg6S6osGY1gbskdx07g7ciKeBQw==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
  • Delivery-date: Mon, 13 Sep 2021 08:54:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

While for now PV domains have a host P2M associated with them and hence
using XENMEM_get_pod_target on such may not be a real problem, calling
p2m_pod_set_mem_target() for a PV domain is surely wrong, even if benign
at present.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
While the output of the two subfunctions is stale by the time the caller
accesses it, I wonder in how far it is helpful to provide potentially
inconsistent values, due to the lack of any respective locking. It just
so happens that "get" has no in-tree caller at all (years ago I did
propose it to be exposed to guests themselves, with no real decision
taken either way), while of the two "set" callers neither cares about
the output.


Furthermore for "set" I also find it concerning that page-alloc-lock
protected data is being accessed without holding that lock. Both
d->max_pages and the result of domain_tot_pages() can change in
parallel. Then again I wonder whether "set" shouldn't be restricted to
before the guest gets actually started.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4786,7 +4786,9 @@ long arch_memory_op(unsigned long cmd, X
         if ( d == NULL )
             return -ESRCH;
-        if ( cmd == XENMEM_set_pod_target )
+        if ( !is_hvm_domain(d) )
+            rc = -EINVAL;
+        else if ( cmd == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(XSM_PRIV, d);
             rc = xsm_get_pod_target(XSM_PRIV, d);



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.