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

["Daniel P. Smith" <dpsmith@apertussolutions.com>]

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@suse.com>
>>>>> ---
>>>>> 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