[svsm-devel] [EXTERNAL] Re: x86 decoder further steps
Jon Lange
jlange at microsoft.com
Tue Apr 30 19:01:14 CEST 2024
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.
-Jon
-----Original Message-----
From: Svsm-devel <svsm-devel-bounces at coconut-svsm.dev> On Behalf Of Carlos López
Sent: Tuesday, April 30, 2024 7:39 AM
To: Thomas Leroy <tleroy at suse.de>
Cc: svsm-devel at coconut-svsm.dev
Subject: [EXTERNAL] Re: [svsm-devel] x86 decoder further steps
[Some people who received this message don't often get email from clopez at suse.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi,
On 30/4/24 11:56, Thomas Leroy wrote:
> Hi everyone,
>
> As you may know, the current #VC handler uses a naive x86 instruction
> decoder
> that is used to find the appropriate NAE event handler to call.
>
> As I said, the current decoder is very naive and does only byte matching to
> identify cpuid, in/out{bwl}, rdmsr/wrmsr, and rdtsc{p} instructions [0].
> Since we currently don't support all NAE events in the #VC handler, we have
> to find a clean way to decode the remaining NAEs.
Yes, it will require at least a small rework to handle instruction
prefixes (namely REP).
> If the decoder's only use is for the #VC handler, I guess we can stick
> to what
> we currently do. It shouldn't be too hard to match the remaining NAE
> instructions
> in the decoder. However, if we need a complete instruction decoder
> somewhere,
> we'll have to decide if we write our own or if we use an existing one.
> I'm not aware of the full SVSM development plan, so I don't really know the
> possible other uses of the decoder.
>
> As you may also noticed, the instruction decoder is an attack surface
> since it
> deals with untrusted raw bytes. For this reason, we should make it as small
> (and secure of course) as possible. So if we finally need a complete
> decoder,
> we'll have to choose between write our own, which will be time consuming and
> could introduce security bugs (especially when #VC exceptions will be raised
> from a less privileged context), or rely on a third-party one (that we
> shouldn't consider prefect security-wise).
>
> What's your opinion between these solutions?
>
> I recently discovered the iced-x86 [1] crate looks easy to incorporate
> to the
> SVSM project, and supports no_std, so I think it would be a candidate.
> Finally, if we go for a third-party one, a security audit of the chosen
> decoder would be needed, at least a fuzzing campaign (I could take care
> of it).
I haven't attempted to the decode the remaining instructions, but other
than the prefix issue I mentioned above I don't think we need much more.
On the other hand, iced-x86 has a lot of features that can be disabled,
since we only want instruction decoding, so we wouldn't be importing
that much code. The project also already has fuzzing, so I assume it's
well tested overall.
> Cheers,
> Thomas
>
> [0]
> https://github.com/coconut-svsm/svsm/blob/104ca723cdd6a272f40c31548dd6c05010494c84/kernel/src/cpu/insn.rs#L110
>
> [1] https://docs.rs/iced-x86/latest/iced_x86/
>
--
Carlos López
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
More information about the Svsm-devel
mailing list