[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 04/17] xen: Introduce XEN_DOMCTL_CDF_not_hypercall_target
- To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Mon, 21 Jul 2025 18:00:19 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/cCpAB8KvxNcnBmB77dLRJvswk7+9p04VmNkA/nZG2U=; b=GxXmDal8Q8+uvk4oqyQwRnfLWJ2+15Ckl3PoL4VkxF81f12/rh2qvLe7ueGz4so1i+9NTHpnCOBHE8maVNI9wLilH+yGqyGfBlrTNzXIQBA049dU1S1IPJvEDtotiL+OZY2xFuigYmRtBxypKbgwYOS1trNp63OfCIVZstze1Ak5BXUhG6+8NJRkC4Jyr2SCVgQ532rW7wePv+TsHzQ539+eAaSj/K1ppk+YNqyhsPlCivFD3v8SF51HAVDgEKEktW4xrEdu4JplqnK+MRTKH59rATKxEIdhWexK5Ow/TjFEBreHSz7rhV0VuakdcAQj6vheqhkmv8J9I6llqGavxQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u6ZJEe8QSPy+s9bQdC7v268UZetTF0shaF2XLG97QyqTp+aVbS9nupk1Z/XSZipmoJ1TrTbcQJzSX0npFVTKu+euV7ctTde0o8C/6/cDUdZBRniA34mlPuM1aPYe5EYhIklFQj20NivFMxdxylqB3YwQhlgpYZvA0St8lRs+LscVz2KpP6dPXZH3un21rVJCYIK7z8C7rLtJ9ev3ouRN41mRMOxis9oSEu6+IXsXsyrfAKS6uMQJYsADczdjHqAeOh9NvM8l8+9YBxmbqoYmza4v3qoHQe1dd/P8RitUbWkZ6cvMQBGWnhPiI5HLSVegWXVEXa1VsX+DcTZLNzxvSg==
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, "David Scott" <dave@xxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 21 Jul 2025 22:02:29 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Julien,
Thanks for taking a look.
On 2025-07-21 13:58, Julien Grall wrote:
Hi Jason,
On 16/07/2025 22:14, Jason Andryuk wrote:
Add a new create domain flag to indicate if a domain can be the target
of hypercalls. By default all domains can be targetted - subject to any
other permission checks.
This property is useful in a safety environment to isolate domains for
freedom from interference.
I see the flag is exposed to the toolstack. However, I don't see how you
can successfully create a VM if you are not allowed to call hypercalls
(for instance to add some memory).
Yes, you are right. With dom0less/Hyperlaunch, I'd not been considering
the toolstack.
I think, at minimum, you would want to allow hypercalls while the domain
is created. That said, I wonder if this setup would not be better to
describe with XSM?
Re-labeling with Flask would allow different permissions between
building and running. domain_unpause would need to be allowed, but that
doesn't stop a domain.
At first glance, like you say, the untargetable property could be
enabled when domain creation finishes.
[...]
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 88a294c5be..f1f6f96bc2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -70,9 +70,11 @@ struct xen_domctl_createdomain {
#define XEN_DOMCTL_CDF_trap_unmapped_accesses (1U << 8)
/* Allow domain to provide device model for multiple other domains */
#define XEN_DOMCTL_CDF_device_model (1U << 9)
+/* Domain cannot be the target of hypercalls */
+#define XEN_DOMCTL_CDF_not_hypercall_target (1U << 10)
/* Max XEN_DOMCTL_CDF_* constant. Used for ABI checking. */
-#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_device_model
+#define XEN_DOMCTL_CDF_MAX XEN_DOMCTL_CDF_not_hypercall_target
I am not sure where to comment. But aren't both flags mutually exclusive?
No, XEN_DOMCTL_CDF_device_model is *this* domain providing the device
model to other domains:
+ * Device model capability allows the use of the dm_op hypercalls to
provide
+ * the device model emulation (run QEMU) for other domains. This is a
+ * subset of the Control capability which can be granted to the
+ * Hardware domain for running QEMU.
Whereas XEN_DOMCTL_CDF_not_hypercall_target removes targeting on *this*
domain. So the domain with XEN_DOMCTL_CDF_device_model cannot target
the XEN_DOMCTL_CDF_not_hypercall_target domain.
Regards,
Jason
|