[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

  • To: xen-devel@xxxxxxxxxxxxx
  • From: Charles Gonçalves <charles.fg@xxxxxxxxx>
  • Date: Thu, 7 Oct 2021 16:10:35 +0100
  • Delivery-date: Thu, 07 Oct 2021 15:11:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Charles Ferreira Gonçalves



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