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

[Dong, Chuanxiao]

> -----Original Message-----
> From: Svsm-devel <svsm-devel-bounces at coconut-svsm.dev> On Behalf Of Dong, Chuanxiao
> Sent: Tuesday, May 7, 2024 3:24 PM
> To: Lange, Jon <jlange at microsoft.com>; Jörg Rödel <joro at 8bytes.org>
> Cc: svsm-devel at coconut-svsm.dev
> Subject: Re: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps
> 
> 
> > -----Original Message-----
> > From: Jon Lange <jlange at microsoft.com>
> > Sent: Tuesday, May 7, 2024 12:31 PM
> > To: Dong, Chuanxiao <chuanxiao.dong at intel.com>; Jörg Rödel
> > <joro at 8bytes.org>
> > Cc: Thomas Leroy <tleroy at suse.de>; Carlos López <clopez at suse.de>;
> > svsm-devel at coconut-svsm.dev
> > Subject: RE: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps
> >
> > 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.
> 
> I think it matches what I though. Below is my understanding, and please let me know if this matches
> with your expectation or not.
> 
> The vmentry has to be happened in the kernel mode as executing the TDCALL instruction in user mode
> will cause #GP, so the user mode will use some sort of syscall to enter the kernel mode to do the
> vmentry. Based on this, the kernel mode is the first place to reach upon a guest vmexit. After identify
> the vmexit reason, the kernel mode can directly perform the instruction decoding if it is needed, and
> pass the decoded MMIO information (like below example) up to the user mode via returning from this
> syscall. And then the user mode performs MMIO emulation, as below example, to return value Y to the
> kernel mode via the syscall when needs to  vmentry again. The kernel mode completes the instruction
> emulation by writing the value Y to the decoded destination register or guest memory, and then
> performs the vmentry.

Some update, we will decouple the instruction decoder from the Intel branch and try to integrate with the coconut-svsm existing one.

Please let us know if there is any further comment.

Thanks
Chuanxiao
> 
> > 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%2F
> > > > gi
> > > > thub.com%2Fintel-staging%2Ftd-partitioning-svsm%2Ftree%2Fsvsm-tdp&
> > > > da
> > > > ta=05%7C02%7Cjlange%40microsoft.com%7Cf0e2c42e6a3145645be208dc6e3b
> > > > ad
> > > > 57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638506449805174183
> > > > %7
> > > > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > > > 6I
> > > > k1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=X2f6LB0t03ylcyYKSqIKrgLgI
> > > > TQ
> > > > 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
> --
> Svsm-devel mailing list
> Svsm-devel at coconut-svsm.dev
> https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel