On 15.05.2025 21:50, Andrew Cooper wrote:
> This is reported as a MISRA R16.3 (missing break) violation, but turns out to
> be substantially more complicated than expected.
> 
> In commit a8fe4ec5320a ("x86emul: support RDRAND/RDSEED"), the switch()
> statement had a default case going to cannot_emulate, with both the case 6 and
> case 7 labels being fully within #ifdef HAVE_GAS_RD{RAND,SEED}.
> 
> Therefore, when the toolchain didn't understand the RDRAND/RDSEED
> instructions, attempts to emulate them suffered #UD.  (This is arguably a
> problem as there's no interlock to prevent RDRAND/RDSEED being advertied to
> the guest, but as instructions with only register encodings, they can only end
> up being emulated with VM Introspection is in use.)
> 
> In commit 58f1bba44033 ("x86emul: support RDPID"), case 7 was taken outside of
> HAVE_GAS_RDSEED, meaning that emulating an RDSEED instruction no longer hit
> the default case when the toolchain was too old.
> 
> Instead, it would fall out of the switch statment and be completed normally,
> behaving as a NOP to the guest.
> 
> Retrofit a "return X86EMUL_UNIMPLEMENTED" in the case that the toolchain
> doesn't know the RDRAND instruction, matching how RDRAND work.
> 
> Note that this has been fixed differently in Xen 4.21.  Commit
> 05bf9f1f0f52 ("x86/emulate: Remove HAVE_AS_RDRAND and HAVE_AS_RDSEED") has
> removed the problematic condition due to the toolchain baseline upgrade.
> 
> Fixes: 58f1bba44033 ("x86emul: support RDPID")
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>

Reviewed-by: Jan Beulich <jbeul...@suse.com>


Reply via email to