Xen Project Release Features/Definitions: Difference between revisions
Lars.kurth (talk | contribs) |
Lars.kurth (talk | contribs) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 101: | Line 101: | ||
Prior to the introduction of [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md], security support could be restricted in the following situations |
Prior to the introduction of [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md], security support could be restricted in the following situations |
||
* A restriction of some configurations as expressed in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/qemu-xen-security xen.git:docs/misc/qemu-xen-security]. From Xen 4.10 exceptions have been encoded in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] |
* A restriction of some configurations as expressed in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/qemu-xen-security xen.git:docs/misc/qemu-xen-security]. From Xen 4.10 exceptions have been encoded in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] |
||
* Docs for an individual feature (eg in xl docs) might say that the feature is not advised, or not supported, or something similar. These restrictions apply for all Xen releases, however [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] would contain a note saying “please check *.doc for additional restrictions” |
* Docs for an individual feature (eg in [http://xenbits.xen.org/docs/unstable/man/xl.1.html xl] docs) might say that the feature is not advised, or not supported, or something similar. These restrictions apply for all Xen releases, however [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] would contain a note saying “please check *.doc for additional restrictions” |
||
* Previous XSA advisories might withdraw support: this will be encoded in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] |
* Previous XSA advisories might withdraw support: this will be encoded in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] |
||
* Experimental KCONFIG tags: by definition, code marked as Experimental by KCONFIG is not security supported. For consistency, we will ensure that [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] captures these items |
* Experimental KCONFIG tags: by definition, code marked as Experimental by KCONFIG is not security supported. For consistency, we will ensure that [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md SUPPORT.md] captures these items |
||
<br> |
|||
{{InfoLeft|Note that for a few releases after Xen 4.10, we expect that we could miss individual examples of the instances described above. In other words, SUPPORT.md may not be filly in sync with what is described above. If you notice an inconsistency, please raise it on xen-devel@, such that we can fix the issue. }} |
{{InfoLeft|Note that for a few releases after Xen 4.10, we expect that we could miss individual examples of the instances described above. In other words, SUPPORT.md may not be filly in sync with what is described above. If you notice an inconsistency, please raise it on xen-devel@, such that we can fix the issue. }} |
||
Latest revision as of 16:37, 12 March 2018
These definitions are based on xen.git:SUPPORT.md, which is a machine readable version of Xen Project Release Features, which was introduced in Xen 4.10. |
The definitions in this document primarily refer to the information in Xen Project Release Features or its archived version.
Definition of Support Labels
Each status value besides a ✓ or ✓ corresponds to levels of security support, testing, stability, etc., as in the following subsections. Note that format in Xen Project Release Features typically follows the following convention
- ✓ [footnote] [support label]
- ✓ [footnote] [support label]
If no support label is specified besides a ✓, the feature is normally considered Supported unless otherwise specified.
Experimental
Functional completeness: No Functional stability: Here be dragons Interface stability: Not stable Security supported: No
Tech Preview
Functional completeness: Yes Functional stability: Quirky Interface stability: Provisionally stable Security supported: No
Supported
Functional completeness: Yes Functional stability: Normal Interface stability: Yes Security supported: Yes
Deprecated
Functional completeness: Yes Functional stability: Quirky Interface stability: No (as in, may disappear the next release) Security supported: Yes
All of these may appear in modified form via footnotes.
Definition of the status label interpretation tags
Functionally complete
Does it behave like a fully functional feature? Yes = ✓
Does it work on all expected platforms, or does it only work for a very specific sub-case? No = ✓
Does it have a sensible UI, or do you have to have a deep understanding of the internals to get it to work properly? No = ✓
Functional stability
What is the risk of it exhibiting bugs?
General answers to the above:
- Here be dragons
- Pretty likely to still crash / fail to work.
- Not recommended unless you like life on the bleeding edge.
- Quirky
- Mostly works but may have odd behavior here and there.
- Recommended for playing around or for non-production use cases.
- Normal
- Ready for production use
Interface stability
If I build a system based on the current interfaces, will they still work when I upgrade to the next version?
- Not stable
- Interface is still in the early stages and still fairly likely to be broken in future updates.
- Provisionally stable
- We're not yet promising backwards compatibility, but we think this is probably the final form of the interface.
- It may still require some tweaks.
- Stable
- We will try very hard to avoid breaking backwards compatibility, and to fix any regressions that are reported.
Security supported
Will XSAs be issued if security-related bugs are discovered in the functionality?
If "no", anyone who finds a security-related bug in the feature will be advised to post it publicly to the Xen Project mailing lists (or contact another security response team, if a relevant one exists).
Bugs found after the end of Security-Support-Until in the Release Support section will receive an XSA if they also affect newer, security-supported, versions of Xen.
However, the Xen Project will not provide official fixes or non-security-supported versions.
Other Documents impacting Security Support
Prior to the introduction of SUPPORT.md, security support could be restricted in the following situations
- A restriction of some configurations as expressed in xen.git:docs/misc/qemu-xen-security. From Xen 4.10 exceptions have been encoded in SUPPORT.md
- Docs for an individual feature (eg in xl docs) might say that the feature is not advised, or not supported, or something similar. These restrictions apply for all Xen releases, however SUPPORT.md would contain a note saying “please check *.doc for additional restrictions”
- Previous XSA advisories might withdraw support: this will be encoded in SUPPORT.md
- Experimental KCONFIG tags: by definition, code marked as Experimental by KCONFIG is not security supported. For consistency, we will ensure that SUPPORT.md captures these items
Interaction with other features
Not all features interact well with all other features. Some features are only for HVM guests; some don't work with migration, &c.
External security support
The Xen Project security team provides security support for Xen Project projects.
We also provide security support for Xen-related code in Linux, which is an external project but doesn't have its own security process.
External projects that provide their own security support for Xen-related features are listed below.