Hello Guys,
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 )
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?
I'm running on intel x64, on paravirtualization mode, the only
difference in the system is the xen version.
Atenciosamente,
Charles Ferreira Gonçalves
