| Message ID | 121c2612-c255-4051-8d7c-315df6b3d348@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] SUPPORT.md: split XSM from Flask | expand |
On 31/07/2024 3:28 pm, 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 mandates SILO for having > a security supported configuration. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > v2: Terminology adjustments. Stronger description. > > --- 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 (Xen Security Module) I'd suggest using Modules (plural) here. > + > + Status: Supported > + > +See below for use with FLASK and SILO. The dummy implementation is covered here > +as well. I still think we want a one-line description of what "dummy" is. "XSM is a security policy framework. The dummy implementation is covered by this statement, and implements a policy whereby dom0 is all powerful. See below for alternative modules (FLASK, SILO)." ? > + > +### FLASK XSM Module > > 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. > > +### SILO XSM Module > + > + Status: Supported "SILO implements a policy whereby domUs can only communicate with dom0, and not with each other" ? ~Andrew
On 31.07.2024 16:59, Andrew Cooper wrote: > On 31/07/2024 3:28 pm, 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 mandates SILO for having >> a security supported configuration. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> v2: Terminology adjustments. Stronger description. >> >> --- 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 (Xen Security Module) > > I'd suggest using Modules (plural) here. But XSM itself is just one thing? >> + >> + Status: Supported >> + >> +See below for use with FLASK and SILO. The dummy implementation is covered here >> +as well. > > I still think we want a one-line description of what "dummy" is. > > "XSM is a security policy framework. The dummy implementation is > covered by this statement, and implements a policy whereby dom0 is all > powerful. See below for alternative modules (FLASK, SILO)." > > ? Hmm, can do. Looking around in some cases we indeed have such explanations. Jan
On 31/07/2024 4:14 pm, Jan Beulich wrote: > On 31.07.2024 16:59, Andrew Cooper wrote: >> On 31/07/2024 3:28 pm, 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 mandates SILO for having >>> a security supported configuration. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> --- >>> v2: Terminology adjustments. Stronger description. >>> >>> --- 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 (Xen Security Module) >> I'd suggest using Modules (plural) here. > But XSM itself is just one thing? In which case "XSM (Xen Security Module) Framework" ? > >>> + >>> + Status: Supported >>> + >>> +See below for use with FLASK and SILO. The dummy implementation is covered here >>> +as well. >> I still think we want a one-line description of what "dummy" is. >> >> "XSM is a security policy framework. The dummy implementation is >> covered by this statement, and implements a policy whereby dom0 is all >> powerful. See below for alternative modules (FLASK, SILO)." >> >> ? > Hmm, can do. Looking around in some cases we indeed have such explanations. Everything which isn't entirely obvious should come with a oneliner explanation. Otherwise, SUPPORT.md is useless to non-Xen developers. ~Andrew
--- 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 (Xen Security Module) + + Status: Supported + +See below for use with FLASK and SILO. The dummy implementation is covered here +as well. + +### FLASK XSM Module 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. +### SILO XSM Module + + Status: Supported + ## Virtual Hardware, Hypervisor ### x86/Nested PV
XSM is a generic framework, which in particular is also used by SILO. With this it can't really be experimental: Arm mandates SILO for having a security supported configuration. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- v2: Terminology adjustments. Stronger description.