[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved load/unload ops



On 11/03/13 13:30, Daniel Kiper wrote:
> On Mon, Mar 11, 2013 at 01:21:30PM +0000, David Vrabel wrote:
>> On 11/03/13 11:17, Daniel Kiper wrote:
>>>
>>> Heh... It looks that there is a misunderstanding. At first I thought
>>> that David was going to replace purgatory functionality by switching
>>> from 64-bit to 32-bit in kexec_reloc. But later I realized that
>>> I missed Xen 64-bit/dom 32-bit case. Now I agree that this switch
>>> must stay as is. However, now I think that there is another
>>> small mistake which should be fixed. Please look above.
>>
>> Which mistake?  I'm not sure what you're referring to.
> 
> I thought about that:
> 
> if ( image->arch == EM_386 )
>   reloc_flags |= KEXEC_RELOC_FLAG_COMPAT;
> 
> It should be change to:
> 
> if ( is_pv_32on64_domain(dom0) )
>   reloc_flags |= KEXEC_RELOC_FLAG_COMPAT;

This isn't a mistake but a deliberate improvement to the old interface.

It is clearer and more useful for this sub-architecture to be explicitly
supplied in the kexec_load call than implicitly through some other
side-channel.

If we go with what you suggest then you prevent kexec from being used
by: a) PVH dom0s; b) suitably privileged service domains; c) 32-bit
guests wanting to load an image with a 64-bit entry point; and d)
possibly other use cases you or I haven't even thought about yet.

David

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.