Re: [PATCH RFC] SUPPORT.md: Make all security support explicit

[George Dunlap <george.dunlap@xxxxxxxxx>]

On Fri, Apr 28, 2023 at 9:12 AM George Dunlap <george.dunlap@xxxxxxxxx> 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@xxxxxxxxx>

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