[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PV - different behavior of pgd_offset in xen 4.6 and 4.13 for GUEST ACCESSIBLE memory area

Thanks for pointing this fix Jan. It helped me a lot.

On Fri, Oct 8, 2021, 10:30 Jan Beulich <jbeulich@xxxxxxxx> wrote:
On 07.10.2021 17:10, Charles Gonçalves wrote:
> During some experiments in my PhD I've tried to reused a code from
> Jann Horn (https://bugs.chromium.org/p/project-zero/issues/detail?id=1184
> ) that used the mapping in
> ```
> 0xffff804000000000 - 0xffff807fffffffff [256GB, 2^38 bytes, PML4:256]
> Reserved for future shared info with the guest OS (GUEST ACCESSIBLE)
> ```
> to map some temporary page table data to be able to attack the system.
> This used to work on Xen 4.6:
> ```
> #define MY_SECOND_AREA 0xffff804000000000ULL
> printk("PML4 entry: 0x%lx\n", (unsigned
> long)pgd_val(*pgd_offset(current->mm, MY_SECOND_AREA)));
> ```
> In xen 4.6 :
> `[ 3632.620105] PML4 entry: 0x183d125067 `
> Returns a valid PGD ( pgd_present(*pdg) == true )
> but has different behavior in Xen 4.13 (despite no change in the
> asm-x86/config.h .
> In xen 4.13:
> `[70386.796119] PML4 entry: 0x800000021a445025`
> Return a bad PGD ( pgd_bad(*pdg) == true )

There's nothing really bad in this entry afaics. The entry is r/o
and nx, yes, but that ought to be fine (i.e. I think pgd_bad() is
too rigid here, but may not be valid to be used on hypervisor
controlled entries in the first place).

> I could not find any reference on the branch RELEASE-4.13.0 of why
> this happens this way.
> Any hint of what is happening here?
> Has Xen changed the way it handles memory from regions in range
> 0xffff804000000000 - 0xffff807fffffffff  across those versions?

Yes - see a5a5d1ee949d ("x86/mm: Further restrict permissions on some
virtual mappings"). The page table arrangement underlying this VA
range isn't part of the ABI, i.e. we're free to change it at any time.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.