Re: [PATCH] x86/pv: Only use the guest frame in pv_map_ldt_shadow_page()

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 7/14/26 3:35 PM, Andrew Cooper wrote:
> pv_map_ldt_shadow_page() takes the whole guest PTE, adds _PAGE_RW to it, then
> installs it into Xen's pagetables.  It has had this behaviour ever since LDT
> support was added in 2003.
>
> However, it allows the guest to control the software available bits and
> cacheability.  This happens to be benign right now, but is bad form.
Considering that w/o the patch guest could control such things ...

> Use only the guest frame, and construct the mapping as regular RW frame, and
> notably includes NX.  This is how the GDT logic already works.
>
> Fixes: 005c2723972f ("Finished virtualisation of x86 LDT")
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> CC: Jan Beulich <jbeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Teddy Astie <teddy.astie@xxxxxxxxxx>
> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>
> For 4.22.  The security team have deemed this not an XSA, but it came
> alarmingly close.
>
> This was found originally in an LLM review of the ASI series, where a real
> vulnerability had been introduced by using one of the software available bits
> to mean "please free this page on unmap".  The LLM did not the issues with
> attributes (the guest could almost load a Shadow Stack mapping, saved only by
> the forced addition of _PAGE_RW), and the cacheability (saved only because of
> how conflicting MTRR and PAT values resolve).
>
> An interesting commit is 928a6621db20 ("Fix bug in new LDT shadow mapping
> code", 2003) which did restrict to the guest frame only, but without inserting
> _PAGE_PRESENT or any other attributes, so got reverted in the following commit
> 6841936e9256.
> ---
... it makes sense to have that in 4.22 release:

Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

Thanks.

~ Oleksii