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

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

[Charles Gonçalves]

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

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

[Jan Beulich]

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

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

[Charles Gonçalves]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

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

On Fri, Oct 8, 2021, 10:30 Jan Beulich <jbeulich@suse.com> 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.
>
> Jan
>
>

[-- Attachment #2: Type: text/html, Size: 2608 bytes --]