On Fri, Apr 28, 2023 at 9:12 AM George Dunlap <[email protected]> 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 <[email protected]> > 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
