Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only

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

On 8/13/26 8:14 AM, Jan Beulich wrote:
> 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 <jbeulich@xxxxxxxx>
> > > > > ---
> > > > > 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.
Oh, it most certainly does affect how a security policy wants to be 
written. Certain mechanisms have properties that provide certain 
assurances and the security architect/policy writer may not want to 
allow the access via mechanisms deemed to have an unacceptable risk.
> > > > 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.
Correct.

> 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.
Agreed, that's why I was trying to say that it appears to have been 
created based on that specific situation. My question is, did this 
situation evolve to no longer be a one-off or can we close the ability 
to map memory this way. The comment alludes that it was a temporary 
method of access, but I haven't studied the path to this check or what 
situations could follow that path today. I have a suspicion that it's no 
longer a one-off situation.
v/r,
dps