On 12.07.2021 22:32, Daniel P. Smith wrote: > The passing of an xsm_default_t at each of the xsm hook call sites > served different functions depending on whether XSM was enabled or not. > When XSM was not enabled it attempted to function as a link-time check > that declared default action at the call site matched the default > declared action for that hook in the dummy policy. When XSM was enabled, > it would just drop the parameter. > > The removal of these values is two fold. They are a redundancy that > provides little context, especially when the value is XSM_OTHER.
For XSM_OTHER I may agree, but in general I find the call-site uses helpful to know at least the rough level of intended restriction. E.g. ... > --- a/xen/arch/x86/cpu/mcheck/mce.c > +++ b/xen/arch/x86/cpu/mcheck/mce.c > @@ -1376,7 +1376,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc) > struct xen_mc_msrinject *mc_msrinject; > struct xen_mc_mceinject *mc_mceinject; > > - ret = xsm_do_mca(XSM_PRIV); > + ret = xsm_do_mca(); ... to now understand what this enforces (or not) I have to go to the actual implementation, even if I only want to know the trivial dummy incarnation of it. This effectively extends the "provides little context" from XSM_OTHER to all hooks. Jan
