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

[Thomas Leroy]

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 experimentation.  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.

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