Re: [PATCH] SUPPORT.md: split XSM from Flask

[Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

---- On Tue, 30 Jul 2024 08:58:03 -0400 Jan Beulich  wrote ---

 > On 30.07.2024 14:35, Andrew Cooper wrote: 
 > > On 30/07/2024 11:57 am, Jan Beulich wrote: 
 > >> XSM is a generic framework, which in particular is also used by SILO. 
 > >> With this it can't really be experimental: Arm enables SILO by default. 
 > > 
 > > It's stronger than this. 
 > > 
 > > XSA-295 makes SILO the only security supported configuration for ARM. 
 >  
 > Okay, switched to "Arm mandates SILO for having a security supported 
 > configuration." 
 >  
 > >> --- a/SUPPORT.md 
 > >> +++ b/SUPPORT.md 
 > >> @@ -768,13 +768,20 @@ Compile time disabled for ARM by default 
 > >> 
 > >>      Status, x86: Supported, not security supported 
 > >> 
 > >> -### XSM & FLASK 
 > >> +### XSM 
 > >> + 
 > >> +    Status: Supported 
 > >> + 
 > >> +See below for use with FLASK and SILO.  The dummy implementation is 
 > >> covered here 
 > >> +as well. 
 > > 
 > > This feels weird, although I can't suggest a better option. 
 > > 
 > > XSM isn't optional; it can't be compiled out, 
 >  
 > How can it not be? There's an "XSM" Kconfig control. 
 >  
 > > nor can the dummy policy, 
 >  
 > In a way. Yet how the dummy policy is instantiated is quite different 
 > between XSM=y and XSM=n. 

I have pointed this out a few times, the difference between XSM=y vs XSM=n 
determines how the dummy policy is embedded into the hypervisor. XSM=n, causes 
the dummy policy hooks to be included directly for the xsm_* hooks. When XSM=y, 
then the callback wrapper functions are used for the xsm_* hooks with dummy 
policy set for the callbacks.

 > > so it's weird to call out what literally cannot have a statement 
 > > different to the rest of Xen. 
 > > 
 > > Combined with ... 
 > > 
 > >> + 
 > >> +### XSM + FLASK 
 > > 
 > > ... this wanting to say "Flask (XSM module/policy)" IMO, maybe what we 
 > > really want is: 
 > > 
 > > ---%<--- 
 > > ### XSM (Xen Security Modules) 
 > > 
 > > Base XSM is a security policy framework used in Xen.  The dummy policy 
 > > implements a basic "dom0 all powerful, domUs all unprivileged" policy". 
 > > ---%<--- 
 > > 
 > > intentionally without giving a Status. 
 >  
 > As per above, imo XSM=y wants security status named. That's, after all, 
 > part of what was missing / ambiguous so far. 
 >  
 > > Then, the two blocks below are clearly alternative modules which have 
 > > optionality and different support statuses. 
 >  
 > I'll change the wording there some, to be closer to what you and also 
 > Daniel ask for. 

Thank you.

dps