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
