[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] PV - different behavior of pgd_offset in xen 4.6 and 4.13 for GUEST ACCESSIBLE memory area
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |