Re: [PATCH 3/6] xsm: enabling xsm to always be included

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.06.2021 23:20, Andrew Cooper wrote:
> 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.

Compared with the full-fledged XSM, I view the present xsm_default_action()
as sufficiently trivial. The inline wrappers of it really only exist to
allow #ifdef-ary at all the use sites to be avoided, and for the code to
act like before XSM got introduced. Whether you call this !XSM or
XSM_HWDOM_ALL_POWERFUL is secondary to me.

> 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.

As said, what you discuss is just how to call the child. What I point out
as undesirable is the going away of the inline functions, replaced by real
function calls (not indirect ones thanks to alternatives patching, but
still not clearly on par with the current model in terms of overhead).

Jan