Re: [Xen-devel] [PATCH v4 2/2] allow hardware domain != dom0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.04.14 at 01:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 15/04/2014 23:07, Daniel De Graaf wrote:
>> On 04/15/2014 10:45 AM, Andrew Cooper wrote:
>>> On 14/04/14 22:23, Daniel De Graaf wrote:
>>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>>> index 3c05711..11c905a 100644
>>>> --- a/xen/common/domain.c
>>>> +++ b/xen/common/domain.c
>>>> @@ -61,6 +61,11 @@ struct domain *domain_list;
>>>>
>>>>   struct domain *hardware_domain __read_mostly;
>>>>
>>>> +#ifdef CONFIG_LATE_HWDOM
>>>> +domid_t hardware_domid __read_mostly;
>>>> +integer_param("hardware_dom", hardware_domid);
>>>> +#endif
>>>> +
>>>
>>> Is it worth putting a custom_param() in here which clamps hardware_domid
>>> below FIRST_RESERVED_DOMID, or allow anyone specifying
>>> hardware_dom=0xffff to keep all the broken pieces they find?  Aliasing
>>> the magic domids is sure to break things.
>>>
>>> ~Andrew
>>
>> I'm currently of the opinion that a custom_param is overkill to prevent
>> users from deliberately doing bad things, but could easily write one if
>> others think that it would be helpful.
>>
> 
> I suppose the answer depends on how subtle the breakage will be if the
> user gets it accidentally wrong.  Given that slightly over half the
> domid space is reserved and domid_t signed value, I can forsee subtle
> bugs if a domid_t ever used as an array index, as well as very unsubtle
> breakage if the user aliases one of the magic domids.
> 
> On the balance, a custom_param() is probably worthwhile for peace of mind.

Why can't we just BUG_ON() or panic() the first time domain_create()
gets to see the out of range domain ID?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel