Re: [PATCH v2 1/2] x86/boot: Fix page table access in 5-level to 4-level paging transition

[Dave Hansen <dave.hansen@intel.com>]

On 10/28/25 03:55, Usama Arif wrote:
> - native_read_cr3_pa(): Uses CR3_ADDR_MASK properly clearing SME encryption
>   bit and extracting only the physical address portion.

I guess we can apply these as-is. They do fix a bug.

But I find these descriptions a bit unsatisfying. CR3_ADDR_MASK happens
to work here on 64-bit. Interestingly enough, it wouldn't have been as
good of a fix on PAE paging because it ignores those upper bits instead
of reserving them.

But CR3_ADDR_MASK doesn't "extract... only the physical address
portion". It also extracts reserved bits.

It also doesn't mention the LAM bits. It's not just SME.

This would be better:

 - native_read_cr3_pa(): Uses CR3_ADDR_MASK to additionally mask
   metadata out of CR3 (like SME or LAM bits). All remaining bits are
   real address bits or reserved and must be 0.

> - mask pgd value with PTE_PFN_MASK instead of PAGE_MASK, accounting for
>   flags above physical address (_PAGE_BIT_NOPTISHADOW in particular).

This also isn't _quite_ right. The "flags above physical" address are
dynamic. They move because the max physical address (MAXPHYADDR) is
enumerated and changes from CPU to CPU.

It's OK in this case because moving MAXPHYADDR down just changes bits
from address bits to reserved (must be 0).

In a perfect world, we would construct a kexec CR3 with the dynamic
MAXPHYADDR (plus masking out the lower 12 bits). That would be obviously
correct for *all* 32-bit and 64-bit cases and wouldn't even rely on
knowing where the boundary is between ignored and reserved. The approach
in these patches is a fine improvement We don't need to be perfect.

Ideally this second bullet would be:

 - mask pgd value with PTE_PFN_MASK instead of PAGE_MASK, accounting for
   flags above bit 51 (_PAGE_BIT_NOPTISHADOW in particular). Bits below
   51, but above the max physical address are reserved and must be 0.

But it's fine-ish as-is.

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>