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

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

On 11/9/26 4:32 AM, Jan Beulich wrote:
> 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 ...
Hi Jan,

Thank you for the reply, and for confirming that the proposed wording
does a reasonable job of separating the maturity of the implementation
from the guarantees (or lack thereof) that any particular policy provides.

I’d like to share a few thoughts on the code-quality and audit points
you raised.

On the idea of a full code audit: I’m not aware of other in-tree
subsystems that have been held at Experimental status pending a complete
audit after bugs were found and fixed in part of the code. Normally
those issues are either fixed or, when appropriate, handled via the
security process. Style differences themselves don’t create functional
defects; they mainly affect readability and review consistency. If the
historical concern was driven largely by style, that feels like a
relatively weak reason to keep the module Experimental.

On the specific issues from that earlier period: the memory-leak fixes
that went in around XSA-84 (and the related work for XSA-85) were
public. If there had been additional material problems at the time that
the security team felt required a broader audit, I would have expected
them to be mentioned alongside those advisories. In the absence of that,
it is hard for me to treat the need for an audit as still open.

From a practical standpoint, I am not claiming the code is bug-free. I
can say that we have run FLASK in production at scale, on devices that
stay up continuously for long periods, without seeing the kind of
stability or resource issues that significant leaks or similar defects
would typically produce. That experience makes me question whether a
full audit is still a necessary gate for moving the module to Supported,
especially given that the proposed text keeps the XSA-77 limitations
explicit.

On style more generally: my recollection was that code brought in from
Linux (as the FLASK security server largely was) would not be required
to match the Xen coding style, so that later updates from Linux would
remain easier to integrate. MISRA compliance is an understandable
exception; pure stylistic divergence is less so. There is still a fair
amount of code elsewhere in the hypervisor that does not fully follow
the current style guidelines and is nonetheless Supported. I would
prefer we not treat style as a blocking issue for an already-in-tree
component.

That said, I saw your recent patch that removes some of the remaining
Linux-origin style artifacts. If the changes look reasonable and do not
make a future import of newer Linux FLASK code more difficult, I am
happy to provide an Ack on it.

Overall, I still think the proposed wording—Supported for the
implementation in xen/xsm/flask, Experimental for the default policy,
and the existing XSA-77 caveats left in place—is a fair reflection of
the current state. If there are concrete, currently open issues that you
believe should be addressed first, I would be glad to look at them.
Otherwise, I would prefer we not let the older style and audit concerns
stand in the way of the status change.

V/r,
Daniel P. Smith