| Message ID | 20210712203233.20289-8-dpsmith@apertussolutions.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xsm: refactoring xsm hooks | expand |
On 12/07/2021 21:32, Daniel P. Smith wrote: > The generic event channel labeling has not been used by any XSM module since > its introduction. This commit removes the capability leaving FLASK labeling > field always present. In the future if a new XSM module needs to have its own > channel label, this or a new form can be introduced. You're missing a SoB line. Also, this too would benefit from being reordered higher than patch 6, to reduce the churn there.
On 7/12/21 7:52 PM, Andrew Cooper wrote: > On 12/07/2021 21:32, Daniel P. Smith wrote: >> The generic event channel labeling has not been used by any XSM module since >> its introduction. This commit removes the capability leaving FLASK labeling >> field always present. In the future if a new XSM module needs to have its own >> channel label, this or a new form can be introduced. > > You're missing a SoB line. Apologies, i was originally going to squash this but then decided it probably served to be kept as a standalone commit. Will get the SoB added. > Also, this too would benefit from being reordered higher than patch 6, > to reduce the churn there. Ack v/r, dps
On 12.07.2021 22:32, Daniel P. Smith wrote: > The generic event channel labeling has not been used by any XSM module since > its introduction. This commit removes the capability leaving FLASK labeling > field always present. In the future if a new XSM module needs to have its own > channel label, this or a new form can be introduced. I'm not fully convinced of this removal: Does it get in the way of anything? > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -120,15 +120,7 @@ struct evtchn > unsigned short notify_vcpu_id; /* VCPU for local delivery notification */ > uint32_t fifo_lastq; /* Data for identifying last queue. */ > > -#ifdef CONFIG_XSM_EVTCHN_LABELING > union { > -#ifdef XSM_NEED_GENERIC_EVTCHN_SSID > - /* > - * If an XSM module needs more space for its event channel context, > - * this pointer stores the necessary data for the security server. > - */ > - void *generic; > -#endif > #ifdef CONFIG_XSM_FLASK > /* > * Inlining the contents of the structure for FLASK avoids unneeded This comment's "with only FLASK" now becomes stale, and hence would imo better be updated. Jan
diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 3b50391392..d03a991183 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -202,17 +202,9 @@ config XENOPROF menu "Xen Security Modules" -config XSM_EVTCHN_LABELING - bool "Enables security labeling of event channels" - default n - help - This enables an XSM module to label and enforce access control over - event channels. - config XSM_FLASK bool "FLux Advanced Security Kernel support" default n - select XSM_EVTCHN_LABELING help Enables FLASK (FLux Advanced Security Kernel) as the access control mechanism used by the XSM framework. This provides a mandatory access diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index aecf0b8424..ef6ba6d791 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -120,15 +120,7 @@ struct evtchn unsigned short notify_vcpu_id; /* VCPU for local delivery notification */ uint32_t fifo_lastq; /* Data for identifying last queue. */ -#ifdef CONFIG_XSM_EVTCHN_LABELING union { -#ifdef XSM_NEED_GENERIC_EVTCHN_SSID - /* - * If an XSM module needs more space for its event channel context, - * this pointer stores the necessary data for the security server. - */ - void *generic; -#endif #ifdef CONFIG_XSM_FLASK /* * Inlining the contents of the structure for FLASK avoids unneeded @@ -138,7 +130,6 @@ struct evtchn uint32_t flask_sid; #endif } ssid; -#endif } __attribute__((aligned(64))); int evtchn_init(struct domain *d, unsigned int max_port);