[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 Thomas Leroy
> Sent: Thursday, May 2, 2024 9:34 PM
> To: Lange, Jon <jlange at microsoft.com>; Carlos López <clopez at suse.de>
> Cc: svsm-devel at coconut-svsm.dev
> Subject: Re: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps
> 
> 
> 
> On 4/30/24 19:01, Jon Lange wrote:
> > As COCONUT-SVSM grows into additional configurations, it will become
> > necessary for the SVSM to emulate MMIO instructions on behalf of the
> > guest OS.  This will require instruction emulation as well.  It would
> > seem a poor choice to have two different instruction emulators for
> > handling #VC and guest instruction emulation.  At the same time, it
> > would be a poor choice to incorporate a fully functional instruction
> > emulator both because it would be big (which has impact both on
> > resources and attack surface) and because it would be excessively
> > flexible (which dramatically increases the possibility of
> > exploitation).  I expect the best strategy would be to continue to
> > expand the existing instruction emulator so it can handle decode of
> > the common MMIO-handling instructions, such as moves (including
> > 16-byte moves), common ALU operations (especially bitwise operations
> > like AND/OR/XOR/BTS/BTR as well as TEST, plus their atomic
> > equivalents), and others that may be determined through experimentati
>  on.  Limiting the scope of emulator capabilities in this way by expanding the existing emulator should
> strike an appropriate balance between functionality and safety.
> I first thought that we could replace our naive decoder by a more complete one, using a third-party crate to
> save time. As said Carlos, we could have only picked the decoder part of the iced-x86 crate to reduce the
> amount of code to import, leaving the emulation part to us.
> However, if we'll never need a much more complete decoder, I agree with you that it's better to add the
> missing NAE events instructions decoding
> + emulation to our existent #VC handling code.

We made a prototype https://github.com/intel-staging/td-partitioning-svsm/tree/svsm-tdp 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?

Thanks
Chuanxiao

> 
> I'm not aware of any potential future needs for a complete decoder (not emulator), but maybe some
> people here do. That was another purpose of my first email. :)
> 
> Thomas
> 
> --
> Thomas Leroy
> Security Engineer
> SUSE Software Solutions
> 
> --
> Svsm-devel mailing list
> Svsm-devel at coconut-svsm.dev
> https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel