[svsm-devel] [EXTERNAL] Re: x86 decoder further steps

[Jon Lange]

My hope is that we can design the user/kernel virtualization ABI to include MMIO primitives, such as "MMIO read requested" and "MMIO write requested".  These primitives would involve performing all of the instruction decoding in kernel mode, so we can take advantage of a single instruction decoder, and that decoder would pass MMIO requests up to user mode.  For example, it might say "vTPM driver: here is a CRB write at address X which contains value Y" or "hey virtual PCI driver: a request was made for config space at address X; please supply value Y to return."  Note that in this model, all of the register manipulation is also hidden in kernel mode so that the kernel/user interface can be limited to address/value pairs for MMIO emulation.  This minimizes the amount of code that needs to be replicated across MMIO handlers and also minimizes the chattiness of the user/kernel interface.

-Jon

-----Original Message-----
From: Dong, Chuanxiao <chuanxiao.dong at intel.com> 
Sent: Monday, May 6, 2024 7:16 PM
To: Jörg Rödel <joro at 8bytes.org>
Cc: Thomas Leroy <tleroy at suse.de>; Jon Lange <jlange at microsoft.com>; Carlos López <clopez at suse.de>; svsm-devel at coconut-svsm.dev
Subject: RE: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps

[You don't often get email from chuanxiao.dong at intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

> -----Original Message-----
> From: Jörg Rödel <joro at 8bytes.org>
> Sent: Friday, May 3, 2024 6:33 PM
> To: Dong, Chuanxiao <chuanxiao.dong at intel.com>
> Cc: Thomas Leroy <tleroy at suse.de>; Lange, Jon <jlange at microsoft.com>; 
> Carlos López <clopez at suse.de>; svsm-devel at coconut-svsm.dev
> Subject: Re: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps
>
> On Fri, May 03, 2024 at 09:23:21AM +0000, Dong, Chuanxiao wrote:
> > We made a prototype
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > thub.com%2Fintel-staging%2Ftd-partitioning-svsm%2Ftree%2Fsvsm-tdp&da
> > ta=05%7C02%7Cjlange%40microsoft.com%7Cf0e2c42e6a3145645be208dc6e3bad
> > 57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638506449805174183%7
> > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> > k1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=X2f6LB0t03ylcyYKSqIKrgLgITQ
> > Aa4r%2BAQpFqCk0YbY%3D&reserved=0 which extended the coconut-SVSM to 
> > support Intel TD partitioned guest.
> > It can decode and emulate some basic MMIO and String I/O 
> > instructions used by the Linux guest. Currently it is part of TD 
> > partitioned guest specific code, but if this code is also helpful to 
> > the NAE events instruction as well, we can see how to integrate it 
> > with the existing decoder?
>
> I agree with Jon that it is best to implement our own limited 
> instruction decoder. This has security advantages as this decoder will 
> be smaller than a more complete one we pull in, which is especially important as instruction decoding will mostly be done in the SVSM kernel for performance reasons.

As you know that, we are going to move parts of this prototype hypervisor code from SVSM kernel to the user space. So based on this,  seems this hypervisor can still decode instructions in the kernel. And completing the instruction emulation, e.g., writing back the MMIO read result (generated by the virtual device model) to the destination vcpu register or guest memory will also be done in the kernel mode, is this a correct understanding?

> So itegrating the MMIO and String I/O emulation support from the Intel 
> branch into our own instruction decoder would be really great.
>
> Regards,
>
>       Joerg