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.coop...@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 > >
