RFC: Promote FLASK XSM Module to Supported in SUPPORT.md

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

Greetings,

This RFC is intended to start a dialogue following the discussion on the 
November Xen Community Call. It proposes changing the status of the 
FLASK XSM Module (the implementation in `xen/xsm/flask`) from 
Experimental to Supported in SUPPORT.md, while leaving the FLASK default 
policy Experimental.
### Background: XSA-77 and disaggregation guidance

XSA-77 ("Disaggregated domain management security status") documented 
that the majority of management hypercalls (most `XEN_DOMCTL_*` subops, 
all of `__HYPERVISOR_sysctl`, certain memory operations, etc.) were 
originally written only for fully-privileged dom0 and had not been 
reviewed for exposure to semi-privileged, potentially hostile callers.
When XSM/FLASK is used to delegate those interfaces, a compromised 
management domain may be able to cause host-wide denial of service or 
privilege escalation. The security team’s policy (codified in “Security 
Status of dom0 disaggregation” section of `docs/misc/xsm-flask.txt`) is 
that, until the interfaces are reviewed, bugs that merely reduce the 
security of a radically disaggregated system to that of a 
non-disaggregated one will be handled as ordinary public bugs rather 
than under the normal security embargo process. Only a small set of 
subops are treated as safe for disaggregation; the remainder listed in 
that section remain covered by the XSA-77 stance.
SUPPORT.md currently reflects this distinction and the XSA-77 caveat for 
FLASK.
### Current status and the case for change

Today, SUPPORT.md divides XSM support between "XSM Framework", "FLASK 
XSM Module", "FLASK default policy", and "SILO XSM Module", where "XSM 
Framework" and "SILO XSM Module" are marked as Supported, and "FLASK XSM 
Module" and "FLASK default policy" are marked Experimental.
The core concern behind XSA-77 is that it has not been demonstrated 
which fine-grained operation delegations can be done safely. The 
documentation provides guidance on “safe”/covered interfaces precisely 
because of that gap. At its heart, this concern is a policy- and 
configuration-level issue.
Marking the code, "FLASK XSM Module", Experimental primarily because a 
user could write an insecure custom policy feels inconsistent. Many 
other knobs in Xen (and in the Linux kernel) allow an administrator to 
weaken isolation or security guarantees; we do not mark the underlying 
code Experimental solely for that reason. An objection to promoting the 
FLASK module should be rooted in concrete problems with the 
implementation in xen/xsm/flask (in the form of patches or defect 
reports), not in the possibility of misconfiguration or vague aspersions 
about code quality.
Real-world use supports treating the module as mature. OpenXT 
derivatives have deployed FLASK-based configurations on the order of 
multiple hundreds of devices for more than 15 years and have undergone 
multiple private security evaluations. In full disclosure, those 
deployments use variations of the OpenXT FLASK policy, not the upstream 
default.
### Proposed SUPPORT.md text

I would like to propose moving "FLASK XSM Module" to Supported status 
with a clear statement of what is supported, while leaving "FLASK 
default policy" as Experimental with a minor clarification.
```
### FLASK XSM Module

    Status: Supported

Compile time disabled by default.

Using FLASK to delegate various domain control hypercalls
to particular other domains, rather than only permitting use by dom0,
remains specifically excluded from security support for many hypercalls.
Please see XSA-77 and the guidance in docs/misc/xsm-flask.txt
for more details. The Supported status of this module reflects the
maturity of the implementation in xen/xsm/flask; any security guarantees
for a particular policy configuration are the responsibility of the
policy author.

### FLASK default policy

    Status: Experimental

The default policy includes FLASK labels and roles for a "typical" 
Xen-based system
with dom0, driver domains, stub domains, domUs, and so on.
No specific validation claims are made for this policy.
```

### Summary

- Promote the FLASK XSM Module (`xen/xsm/flask`) to Supported.
- Leave the FLASK default policy Experimental, with a minor 
clarification on default policy validation claims.
- Retain the existing note that delegating the XSA-77-covered interfaces 
remains outside security support, consistent with the guidance already 
in `xsm-flask.txt`.
I would value feedback, especially from anyone who has concrete concerns 
about the quality or correctness of the FLASK implementation itself.
--
V/r,
Daniel P. Smith
Apertus Solutions, LLC