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 PVOn 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
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
---- 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
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
---- 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
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
---- 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
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
© 2016 - 2024 Red Hat, Inc.