Re: Best way to use altp2m to support VMFUNC EPT-switching?

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/03/2023 2:01 am, Johnson, Ethan wrote:
> Hi all,
>
> I'm looking for some pointers on how Xen's altp2m system works and how it's 
> meant to be used with Intel's VMFUNC EPT-switching for secure isolation 
> within an HVM/PVH guest's kernelspace.
>
> Specifically, I am attempting to modify Xen to create (on request by an 
> already-booted, cooperative guest with a duly modified Linux kernel) a second 
> set of extended page tables that have access to additional privileged regions 
> of host-physical memory (specifically, a page or two to store some sensitive 
> data that we don't want the guest kernel to be able to overwrite, plus some 
> host-physical MMIO ranges, specifically the xAPIC region). The idea is that 
> the guest kernel will use VMFUNC to switch to the alternate EPTs and call 
> "secure functions" provided (by the hypervisor) as read-only code to be 
> executed in non-root mode on the alternate EPT, allowing certain VM-exit 
> scenarios (namely, sending an IPI to another vCPU of the same domain) to be 
> handled without exiting non-root mode. Hence, these extra privileged pages 
> should only be visible to the alternative p2m that the "secure realm" 
> functions live in. (Transitions between the secure- and insecure-realm EPTs 
> will be through special read-only "trampoline" code pages that ensure the 
> untrusted guest kernel can only enter the secure realm at designated entry 
> points.)
>
> Looking at Xen's existing altp2m code, I get the sense that Xen is already 
> designed to support something at least vaguely like this. I have not, 
> however, been able to find much in the way of documentation on altp2m, so I 
> am reaching out to see if anyone can offer pointers on how to best use it.
>
> What is the intended workflow (either in the toolstack or within the 
> hypervisor itself) for creating and configuring an altp2m that should have 
> access to additional host-physical frames that are not present in the guest's 
> main p2m?
>
> FWIW, once the altp2m has been set up in this fashion, we don't anticipate 
> needing to fiddle with its mappings any further as long as the guest is 
> running (so I'm thinking *maybe* the "external" altp2m mode will suffice for 
> this). In fact, we may not even need to have any "overlap" between the 
> primary and alternative p2m except the trampoline pages themselves (although 
> this aspect of our design is still somewhat in flux).
>
> I've noticed a function, do_altp2m_op(), in the hypervisor 
> (xen/arch/x86/hvm/hvm.c) that seems to implement a number of altp2m-related 
> hypercalls intended to be called from the dom0. Do these hypercalls already 
> provide a straightforward way to achieve my goals described above entirely 
> via (a potentially modified version of) the dom0 toolstack? Or would I be 
> better off creating and configuring the altp2m from within the hypervisor 
> itself, since I want to map low-level stuff like xAPIC MMIO ranges into the 
> altp2m?
>
> Thank you in advance for your time and assistance!

Hello,

There's a lot to unpack here, but before I do so, one question.  In your
usecase, are you wanting to map any frames with reduced permissions
(i.e. such that you'd get a #VE exception), or are you just looking to
add new frames with RWX perms into an alternative view?

I suspect the latter, but it's not completely clear, and changes the answer.

~Andrew