Thanks again Andrew, ...

My initial idea was to allocate a frame on kernel space and change the
update_va_mapping to "forcibly" write the desired MFN as the l1 page table
and return the va.

You can see what I did here:
https://github.com/charlesfg/xen/blob/5755f0752bd50891942768bf99898bbc8f7eac82/xen/arch/x86/mm.c#L4539

Basically, I assume the fast path and for the UPDATE_ENTRY
https://github.com/charlesfg/xen/blob/5755f0752bd50891942768bf99898bbc8f7eac82/xen/arch/x86/mm.c#L2184


Any help on this would be greatly appreciated  :)


Atenciosamente,
*Charles Ferreira Gonçalves *




On Tue, Apr 20, 2021 at 7:05 PM Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 20/04/2021 17:13, Charles Gonçalves wrote:
> > Hello Guys,
> >
> > I'm trying to reproduce old exploit behaviors in a simplistic way:
> > create an hypercall to write a buffer to a specific MFN.
> >
> > At first, I thought that updating an l1 page in a valid VA in guest
> > kernel space would do the trick.
> > But for addresses outside the  Guest-defined use (0x0000000000000000 -
> > 0x00007fffffffffff ) is a no go!
> > I get a page fault with  'reserved bit in page table' warning message.
> >
> > Now I'm trying to write to the address inside the hypervisor code, but
> > not sure how to do it.
> >
> > Any comments or tips on this?
>
> So you're looking to add a hypercall to make arbitrary unaudited changes
> to arbitrary memory, to simulate past security issues?
>
> If you're seeing "Reserved bit in page table" then you've managed to
> corrupt a pagetable entry somehow.  Xen doesn't write any reserved bits
> (which it doesn't know how to interpret).
>
> I'm afraid that if you want any further help with this specific failure,
> you're going to have to post your changes to Xen somewhere.  pastebin,
> or a pointer to a git branch, or whatever, but my divination skills
> aren't great...
>
> ~Andrew
>
>