[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. Best!
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.
Jan
|
