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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.11.2026 16:37, Daniel P. Smith wrote:
> 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.

I don't uniformly agree with all you said, but rather than responding
right away I'm going to suggest this as a topic for discussion among
the committers first. I hope that's okay with you.

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

Please do. It's not so much a style change anyway. May I also remind you
that the tail 6 (or so) patches of "XSM: follow-on to XSAs 492 and 499"
are still awaiting an ack of yours?

Jan