On 18/06/2021 13:26, Jan Beulich wrote: > On 18.06.2021 01:39, Daniel P. Smith wrote: >> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO >> and !CONFIG_XSM_FLASK >> is whether the XSM hooks in dummy.h are called as static inline functions or >> as function >> pointers to static functions. As such this commit, >> * eliminates CONFIG_XSM > Following from what Andrew has said (including him mentioning your > changing of certain Kconfig option defaults), I'm not convinced this is > a good move. This still ought to serve as the overall XSM-yes-or-no > setting. If internally you make said two variants match in behavior, > that's a different thing.
I firmly disagree. There is no such thing as !XSM even in staging right now. All over Xen, we have calls to xsm_*() functions which, even in the !XSM case, contain a non-trivial security policy. The fact that under the hood, XSM vs !XSM creates two very different implementations of "the dom0-all-powerful model" is an error needing correcting, as it contributes a massive quantity of code complexity. This series of Daniel's takes steps to make the code match reality, and getting rid of CONFIG_XSM is absolutely the right thing to do. XSM is never actually absent from a build of Xen, even if you choose CONFIG_XSM=n. I do think that the thing we currently call XSM_DUMMY wants renaming to indicate that it is "the dom0-all-powerful" security model, and I think that wants doing as part of this series. Name suggestions welcome. ~Andrew
