Thanks for pointing this fix Jan. It helped me a lot. Best! On Fri, Oct 8, 2021, 10:30 Jan Beulich <jbeul...@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 > >
