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

Reply via email to