| Message ID | 20230428081231.2464275-1-george.dunlap@cloud.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] SUPPORT.md: Make all security support explicit | expand |
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: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 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
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
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
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(+)