On 13.08.2026 13:51, Daniel P. Smith wrote: > On 8/3/26 6:11 AM, Jan Beulich wrote: >> On 02.08.2026 17:55, Daniel P. Smith wrote: >>> On 7/28/26 9:18 AM, Jan Beulich wrote: >>>> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1. >>>> With the function compiled out, its dedicated XSM hook also becomes >>>> unreachable, so it is similarly guarded. >>>> >>>> Signed-off-by: Jan Beulich <[email protected]> >>>> --- >>>> It feels suspicious that the .priv_mapping() check is used for HVM guests >>>> in shadow mode, but not for ones in HAP mode. >>> >>> I believe a hint to it is laying in the comment, >>> >>> /* >>> * Let privileged domains transfer the right to map their target >>> * domain's pages. This is used to allow stub-domain pvfb export to >>> * dom0, until pvfb supports granted mappings. At that time this >>> * minor hack can go away. >>> */ >>> >>> Correct me if I am wrong, but get_page_from_l1e() is only used by PV and >>> HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done >>> through p2m_get_foreign() which will then be covered by >>> xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check. >> >> Yes, sure; that wasn't the point of my comment. The point was that I'd >> expect _the same_ hook to be used by the other path. Aiui if you make a >> policy, you want same situations dealt with the same. Hence there shouldn't >> be a need to express the same thing two ways. > > But it's not the same, the enforcement mechanism is different. FLASK is > an evaluation of Subject/Object/Predicate. In this case the mechanism > (software enforced access) that provides the Predicate has enough risk > that it warranted itself a separate check to allow fine grained > assignment of the operation to a specific domain which was driven by a > specific use case.
I don't understand this. What mode a guest is run in (HAP vs shadow) shouldn't affect what permissions it has. Two distinct hooks means the guest might change behavior when flipped between hap=0 and hap=1. Which absolutely shouldn't happen, imo. >>> I think the question is how to address the TARGET_HACK situation. >> >> I fear I don't really know what exactly you mean here. > > Is this path still needed for the pvfb or is it now in use by other use > cases. If the former, then close the ability otherwise TARGET_HACK > should be renamed to something sensible for general case. Some code > documentation might be necessary to help understand why/ Only after grep-ing it has become apparent that TARGET_HACK is something in Flask. It's entirely invisible outside of Flask, e.g. at the call site of the hook. I think the comment is stale in referencing only pvfb, but I'm not really sure. It is too long ago that I last saw the log message issued there, and hence I don't recall under what (buggy guest?) conditions it could surface. Jan
