Hi Daniel,
On 31/03/2022 00:05, Daniel P. Smith wrote:
There are now instances where internal hypervisor logic needs to make resource
allocation calls that are protected by XSM checks. The internal hypervisor logic
is represented a number of system domains which by designed are represented by
non-privileged struct domain instances. To enable these logic blocks to
function correctly but in a controlled manner, this commit introduces a pair
of privilege escalation and demotion functions that will make a system domain
privileged and then remove that privilege.
Signed-off-by: Daniel P. Smith <dpsm...@apertussolutions.com>
---
xen/include/xsm/xsm.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index e22d6160b5..157e57151e 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -189,6 +189,28 @@ struct xsm_operations {
#endif
};
+static always_inline int xsm_elevate_priv(struct domain *d)
+{
+ if ( is_system_domain(d) )
+ {
+ d->is_privileged = true;
The call for xsm_elevate_priv() cannot be nested. So I would suggest to
check if d->is_privileged is already true and return -EBUSY in this case.
+ return 0;
+ }
+
+ return -EPERM;
+}
+
+static always_inline int xsm_demote_priv(struct domain *d)
+{
+ if ( is_system_domain(d) )
+ {
+ d->is_privileged = false;
+ return 0;
+ }
+
+ return -EPERM;
+}
+
#ifdef CONFIG_XSM
extern struct xsm_operations *xsm_ops;
Cheers,
--
Julien Grall
