[PATCH] SUPPORT.md: split XSM from Flask

[PATCH] SUPPORT.md: split XSM from Flask

[Jan Beulich]

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.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 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.
+
+### XSM + FLASK
 
     Status: Experimental
 
 Compile time disabled by default.
 
-Also note that using XSM
+Also note that using FLASK
 to delegate various domain control hypercalls
 to particular other domains, rather than only permitting use by dom0,
 is also specifically excluded from security support for many hypercalls.
@@ -787,6 +794,10 @@ Please see XSA-77 for more details.
 The default policy includes FLASK labels and roles for a "typical" Xen-based system
 with dom0, driver domains, stub domains, domUs, and so on.
 
+### XSM + SILO
+
+    Status: Supported
+
 ## Virtual Hardware, Hypervisor
 
 ### x86/Nested PV

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

[Daniel Smith]

---- On Tue, 30 Jul 2024 06:57:08 -0400 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. 
 >  
 > Signed-off-by: Jan Beulich jbeulich@suse.com> 
 >  
 > --- 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. 
 > + 
 > +### XSM + FLASK 

To me it would make more sense to say XSM FLASK Policy than XSM + FLASK.

 >  Status: Experimental 
 >  
 >  Compile time disabled by default. 
 >  
 > -Also note that using XSM 
 > +Also note that using FLASK 
 >  to delegate various domain control hypercalls 
 >  to particular other domains, rather than only permitting use by dom0, 
 >  is also specifically excluded from security support for many hypercalls. 
 > @@ -787,6 +794,10 @@ Please see XSA-77 for more details. 
 >  The default policy includes FLASK labels and roles for a "typical" Xen-based system 
 >  with dom0, driver domains, stub domains, domUs, and so on. 
 >  
 > +### XSM + SILO 

Same here, XSM SILO Policy.

 > +    Status: Supported 
 > + 
 >  ## Virtual Hardware, Hypervisor 
 >  
 >  ### x86/Nested PV 
 > 

v/r,
dps

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

[Jan Beulich]

On 30.07.2024 13:37, Daniel Smith wrote:
> ---- On Tue, 30 Jul 2024 06:57:08 -0400 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. 
>  >  
>  > Signed-off-by: Jan Beulich jbeulich@suse.com> 
>  >  
>  > --- 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. 
>  > + 
>  > +### XSM + FLASK 
> 
> To me it would make more sense to say XSM FLASK Policy than XSM + FLASK.

I thought about using "policy", but then deemed that wrong. The "Flask
policy" is what you load into Flask. Whereas here we're talking about the
code actually carrying out what such a policy says.

Jan

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

[Daniel Smith]

---- On Tue, 30 Jul 2024 08:04:09 -0400 Jan Beulich  wrote ---

 > On 30.07.2024 13:37, Daniel Smith wrote: 
 > > ---- On Tue, 30 Jul 2024 06:57:08 -0400 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. 
 > >  > 
 > >  > Signed-off-by: Jan Beulich jbeulich@suse.com> 
 > >  > 
 > >  > --- 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. 
 > >  > + 
 > >  > +### XSM + FLASK 
 > > 
 > > To me it would make more sense to say XSM FLASK Policy than XSM + FLASK. 
 >  
 > I thought about using "policy", but then deemed that wrong. The "Flask 
 > policy" is what you load into Flask. Whereas here we're talking about the 
 > code actually carrying out what such a policy says. 
 
The main issue I have is the "+", so I checked how the different security models/policies are referenced under LSM. The documentation I reviwed lists them as modules or security modules, e.g. AppArmor module. How about one of these combinations, FLASK Module, XSM FLASK Module, or FLASK XSM Module? And similar for SILO.

dps

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

[Jan Beulich]

On 30.07.2024 14:31, Daniel Smith wrote:
> ---- On Tue, 30 Jul 2024 08:04:09 -0400 Jan Beulich  wrote ---
> 
>  > On 30.07.2024 13:37, Daniel Smith wrote: 
>  > > ---- On Tue, 30 Jul 2024 06:57:08 -0400 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. 
>  > >  > 
>  > >  > Signed-off-by: Jan Beulich jbeulich@suse.com> 
>  > >  > 
>  > >  > --- 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. 
>  > >  > + 
>  > >  > +### XSM + FLASK 
>  > > 
>  > > To me it would make more sense to say XSM FLASK Policy than XSM + FLASK. 
>  >  
>  > I thought about using "policy", but then deemed that wrong. The "Flask 
>  > policy" is what you load into Flask. Whereas here we're talking about the 
>  > code actually carrying out what such a policy says. 
>  
> The main issue I have is the "+", so I checked how the different security models/policies are referenced under LSM. The documentation I reviwed lists them as modules or security modules, e.g. AppArmor module. How about one of these combinations, FLASK Module, XSM FLASK Module, or FLASK XSM Module?

Either of the latter two are fine(ish) by me. My (smaller) concern there is
that the M in XSM also stands for Module.

Jan

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

[Andrew Cooper]

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.

And since then, no-one has added LSE atomic support to ARM, so this is
still the case even on hardware which can be driven in a way which isn't
susceptible to LL/SC infinite loops...

>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- 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, nor can the dummy policy,
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.

Then, the two blocks below are clearly alternative modules which have
optionality and different support statuses.

~Andrew

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

[Jan Beulich]

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.

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

Jan

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

[Daniel Smith]

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

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

[Jan Beulich]

On 30.07.2024 15:04, Daniel Smith wrote:
> ---- 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.

I wonder what you're trying to tell me. According to my reading that's what
I said, just in far fewer words.

Jan