The initial goal of SUPPORT.md was to help both users, and the Xen
Project Security Team, determine what functionality was security
supported; i.e., what kinds of security bugs would trigger an XSA.

Our proposal is that as of 4.18, all functionality not explicitly
listed as security supported will be considered not security
supported.  Add some text to that effect.

The patch as written cannot be applied, since specifying "xl.cfg core
functionality" is a TODO; but it should do to start a discussion.

Signed-off-by: Georg Dunlap <george.dunlap@cloud.com>
---
CC: Wei Liu <wl@xen.org>
CC: Andrew Cooper <andrew.cooper@cloud.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monne <roger.pau@cloud.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
---
 SUPPORT.md | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index aa1940e55f..fcbcb44c44 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -17,6 +17,36 @@ for the definitions of the support status levels etc.
 Release Notes
 : <a href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes">RN</a>
 
+# General security support
+
+An XSA will always be issued for security-related bugs which are
+present in a "plain vanilla" configuration.  A "plain vanilla"
+configuration is defined as follows:
+
+* The Xen hypervisor is built from a tagged release of Xen, or a
+  commit which was on the tip of one of the supported stable branches.
+
+* The Xen hypervisor was built with the default config for the platform
+
+* No Xen command-line parameters were specified
+
+* No parameters for Xen-related drivers in the Linux kernel were specified
+
+* No modifications were made to the default xl.conf
+
+* xl.cfg files use only core functionality
+
+* Alternate toolstacks only activate functionality activated by the
+  core functionality of xl.cfg files.
+
+Any system outside this configuration will only be considered security
+supported if the functionality is explicitly listed as supported in
+this document.
+
+If a security-related bug exits only in a configuration listed as not
+security supported, the security team will generally not issue an XSA;
+the bug will simply be handled in public.
+
 # Feature Support
 
 ## Kconfig
-- 
2.25.1

On 28.04.2023 10:12, George Dunlap wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -17,6 +17,36 @@ for the definitions of the support status levels etc.
>  Release Notes
>  : <a href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes">RN</a>
>  
> +# General security support
> +
> +An XSA will always be issued for security-related bugs which are
> +present in a "plain vanilla" configuration.  A "plain vanilla"
> +configuration is defined as follows:
> +
> +* The Xen hypervisor is built from a tagged release of Xen, or a
> +  commit which was on the tip of one of the supported stable branches.
> +
> +* The Xen hypervisor was built with the default config for the platform
> +
> +* No Xen command-line parameters were specified
> +
> +* No parameters for Xen-related drivers in the Linux kernel were specified
> +
> +* No modifications were made to the default xl.conf
> +
> +* xl.cfg files use only core functionality
> +
> +* Alternate toolstacks only activate functionality activated by the
> +  core functionality of xl.cfg files.
> +
> +Any system outside this configuration will only be considered security
> +supported if the functionality is explicitly listed as supported in
> +this document.
> +
> +If a security-related bug exits only in a configuration listed as not
> +security supported, the security team will generally not issue an XSA;
> +the bug will simply be handled in public.

In this last paragraph, did you perhaps mean "not listed as security
supported"? Otherwise we wouldn't improve our situation, unless I'm
misunderstanding and word order doesn't matter here in English. In which
case some unambiguous wording would need to be found.

Jan

On Tue, May 2, 2023 at 12:19 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 28.04.2023 10:12, George Dunlap wrote:
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -17,6 +17,36 @@ for the definitions of the support status levels etc.
> >  Release Notes
> >  : <a href="
> https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes">RN</a>
> >
> > +# General security support
> > +
> > +An XSA will always be issued for security-related bugs which are
> > +present in a "plain vanilla" configuration.  A "plain vanilla"
> > +configuration is defined as follows:
> > +
> > +* The Xen hypervisor is built from a tagged release of Xen, or a
> > +  commit which was on the tip of one of the supported stable branches.
> > +
> > +* The Xen hypervisor was built with the default config for the platform
> > +
> > +* No Xen command-line parameters were specified
> > +
> > +* No parameters for Xen-related drivers in the Linux kernel were
> specified
> > +
> > +* No modifications were made to the default xl.conf
> > +
> > +* xl.cfg files use only core functionality
> > +
> > +* Alternate toolstacks only activate functionality activated by the
> > +  core functionality of xl.cfg files.
> > +
> > +Any system outside this configuration will only be considered security
> > +supported if the functionality is explicitly listed as supported in
> > +this document.
> > +
> > +If a security-related bug exits only in a configuration listed as not
> > +security supported, the security team will generally not issue an XSA;
> > +the bug will simply be handled in public.
>
> In this last paragraph, did you perhaps mean "not listed as security
> supported"? Otherwise we wouldn't improve our situation, unless I'm
> misunderstanding and word order doesn't matter here in English. In which
> case some unambiguous wording would need to be found.
>

No, I think your wording is more accurate.

 -George

On Fri, Apr 28, 2023 at 9:12 AM George Dunlap <george.dunlap@cloud.com>
wrote:

> The initial goal of SUPPORT.md was to help both users, and the Xen
> Project Security Team, determine what functionality was security
> supported; i.e., what kinds of security bugs would trigger an XSA.
>
> Our proposal is that as of 4.18, all functionality not explicitly
> listed as security supported will be considered not security
> supported.  Add some text to that effect.
>
> The patch as written cannot be applied, since specifying "xl.cfg core
> functionality" is a TODO; but it should do to start a discussion.
>
> Signed-off-by: Georg Dunlap <george.dunlap@cloud.com>
>
One of the interesting outcomes of this thought process is that
"supported" is really about the configuration of the system (including
guests):

1. Where it came from
2. How it was build configured
3. Xen command-line parameters
4. Configuration of Xen-related kernel drivers
5. Configuration of support infrastructure; namely xenstore
6. Configuration of guests

That means that in particular, we need to somehow make it clear which
of the hundreds of Xen command-line parameters are OK to modify and
how.

It occurred to me that in many (most? all?) cases it would be more
effective to define the security support parameters in the
documentation itself.

e.g.:

```pandoc
### invpcid (x86)
> `= <boolean>`

> Default: `true`

> Supported values: all

By default, Xen will use the INVPCID instruction for TLB management if
it is available.  This option can be used to cause Xen to fall back to
older mechanisms, which are generally slower.
```

or (for example):

```pandoc
### loglvl
> `= <level>[/<rate-limited level>]` where level is `none | error | warning
| info | debug | all`

> Default: `loglvl=warning`

> Supported values: `none, error, warning`

> Can be modified at runtime

Set the logging level for Xen.  Any log message with equal more more
importance will be printed.

The optional `<rate-limited level>` option instructs which severities
should be rate limited.
```

Since people are (at least somewhat) used to documenting their
features, this would prompt people to consider the security
implications explicitly as they're adding features, rather than having
it be in a separate document.

Another option would be to have a section of the doc where we list
supported hypervisor parameters; e.g.:


```markdown
# Xen command-line arguments

...
invpcid
...
loglvl {none, error, warning}
...
```

It's tempting to consider the idea of listing the options that
*aren't* supported; but that puts us back where we are now, where new
features end up supported by default unless we remember to list them
as unsupported.

Finally, what might be particularly useful is a tool which looks at
the Xen Kconfig value from hypfs, the Xen command-line, and a bunch of
other parameters, and tells you if it sees anything running in the
system that's unsupported.  The challenge there is making it reliable
enough that a "clean bill of health" is actually an accurate
indication that nothing unsupported is being run.

 -George

On 28.04.2023 10:14, George Dunlap wrote:
> On Fri, Apr 28, 2023 at 9:12 AM George Dunlap <george.dunlap@cloud.com> wrote:
> It occurred to me that in many (most? all?) cases it would be more
> effective to define the security support parameters in the
> documentation itself.

I think I agree; the alternative of needing to look in two places (one
telling the syntax, the other telling whether it's "legitimate" to use)
would be prone to people omitting the 2nd step. And this isn't going to
be meaningfully more work right now: Any option we don't mean to
security-support won't need annotating, i.e. like in SUPPORT.md absence
of an explicit statement would mean "not supported".

While in the examples you list only command line options, I guess the
same could apply to xl.cfg / xl.conf ones? Albeit I notice xl.cfg.5.pod.in
in its title specifically says "syntax" right now, which then may want
changing.

For Kconfig items it's not as clear, because I wouldn't consider the
various Kconfig files "documentation", yet I guess we shouldn't require
people to look at source code.

Jan