Re: [PATCH] xen/arm: Prevent Dom0 to be loaded when using dom0less

[Luca Fancellu <luca.fancellu@xxxxxxx>]

Hi Julien,

I will create a new serie with all the improvements we have discussed.

Thank you for your time.

Cheers,

Luca

> On 18 Mar 2021, at 11:13, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 17/03/2021 17:04, Luca Fancellu wrote:
>> Hi,
> 
> Hi Luca,
> 
>> I’ve checked the common code and the arm part, I can confirm that the domid 
>> 0 is never allocated even if the domain 0 is not present, here the only 
>> places where domain_create(…) is called using a variable value:
> 
> Thanks for checking it!
> 
> 
>> 1) xen/arch/arm/domain_build.c
>> d = domain_create(++max_init_domid, &d_cfg, false);
>> Where max_init_domid has value 0 and it is defined in setup.c
> 
> We might want to add a comment on top of this code to explain why the '++a' 
> rather than 'a++'.
> 
>> 2) xen/common/domctl.c
>> d = domain_create(dom, &op->u.createdomain, false);
>> For me seems that the dom variable won’t take the 0 value, if someone could 
>> give another feedback it would be great.
>> On every other part where domain_create(…) is used, it is called with a 
>> constant value different from 0.
> 
> I agree with the analysis. However, I feel this is fragile because we rely on 
> the caller to never pass 0. But it looks like domain_create() doesn't check 
> if the ID is already used. So it would already be possible to overwrite 
> hardware_domain.
> 
> Therefore, this can probably be deffered.
> 
>> For the hardware_domain being NULL and not handled in some situation, it 
>> seems that it’s not directly related to this patch, but I can handle it on a 
>> next serie, from a quick look it seems that many cases can be handled by 
>> checking if the domain is NULL in is_hardware_domain(…).
> 
> Before this series, it is not possible to have hardware_domain == NULL at 
> runtime because dom0 is always created.
> 
> Cheers,
> 
> -- 
> Julien Grall