Thanks Andrew, I'll certainly follow your suggestion of getting used to coding into Xen context. I've just got started programming into Xen, and this will be crucial to my goal.
Right now, my approach to detect a dom0 memory page is to walk across all pages in memory and identify one that holds an unspecific start_info struct, and then check the SIF_INITDOMAIN. If I had a way to identify which domU this unspecific page referee to from this data structure, it will ease the work. Atenciosamente, *Charles Ferreira Gonçalves * On Mon, Jan 4, 2021 at 6:18 PM Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 02/01/2021 19:20, Charles Gonçalves wrote: > > Sure. > > > > The goal is to emulate a scenario where a compromised guest attacks > > another > > tenant in the same physical host reading/changing the memory content. > > E.g., extract the RSA key. > > > > I'll be in the domU kernel space. I'm assuming that the guest is able > > to exploit > > any vulnerability possible. > > Effectively I'll be changing Xen's code (at least possible) to > > *emulate* a vulnerability > > (e.g., undo a patch). > > Ok, so in this scenario, you've successfully exploited a privilege > escalation vulnerability in Xen and obtained code execution in > hypervisor context. There are some security fixes to choose to revert > for this purpose, but none I'm aware of which will make the attack > payload trivial to pull off. > > However, I'd suggest that you first try writing a new hypercall to do > what you want, so you can get used to coding in Xen context, before > adding the complexity of trying to retrofit it into an attack payload. > > If you've already got code with works for dom0, I presume you're keying > off the hardware_domain pointer? Either way, you can look at the > for_each_domain() construct for how to walk the domain list, or > get_domain_by_id() for how to use the hashtable to look up a domain by > its domid. > > ~Andrew >
