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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.11.2026 17:19, Daniel P. Smith wrote:
> 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.

My recollection is a different one: There were concerns over code quality.
For example I seem to recall concerns over there being memory leaks. As a
result I further recall that the security team said that a full code audit
may be necessary to actually address those concerns. To possibly soften
this some, that concern may, to a degree, have been driven by the large
number of style violations in that part of the code base.

At the same time, yes, code and what can be done with it by careless
writing of policies want separating. This looks to be suitably reflected
in your proposed wording change ...

> ### 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.

... here.

Jan