On 17.06.2025 08:53, Nicola Vetrini wrote: > On 2025-06-17 08:19, Jan Beulich wrote: >> On 17.06.2025 03:15, dm...@proton.me wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -743,32 +743,75 @@ int arch_sanitise_domain_config(struct >>> xen_domctl_createdomain *config) >>> return 0; >>> } >>> >>> +/* >>> + * Verify that the domain's emulation flags resolve to a supported >>> configuration. >>> + * >>> + * This ensures we only allow a known, safe subset of emulation >>> combinations >>> + * (for both functionality and security). Arbitrary mixes are likely >>> to cause >>> + * errors (e.g. null pointer dereferences). >>> + * >>> + * NB: use the internal X86_EMU_XXX symbols, not the public >>> XEN_X86_EMU_XXX >>> + * symbols, to take build-time config options (e.g. CONFIG_HVM) into >>> account >>> + * for short-circuited emulations. >>> + */ >>> static bool emulation_flags_ok(const struct domain *d, uint32_t >>> emflags) >>> { >>> + enum domain_capability { >>> + CAP_PV = BIT(0, U), >>> + CAP_HVM = BIT(1, U), >>> + CAP_HWDOM = BIT(2, U), >>> + CAP_DOMU = BIT(3, U), >>> + }; >>> + static const struct { >>> + enum domain_capability caps; >>> + uint32_t min; >>> + uint32_t opt; >>> + } configs[] = { >>> +#ifdef CONFIG_PV >>> + /* PV dom0 and domU */ >>> + { >>> + .caps = CAP_PV | CAP_HWDOM | CAP_DOMU, >> >> Just to double check - are we sure Misra / Eclair will like this >> (ab)use >> of an enum? > > Likely not, but x86_64 is build with CONFIG_PV=n
CONFIG_HVM code further down in the patch is pretty similar. Jan