Re: [Xen-devel] [PATCHv9 0/9] Xen: extend kexec hypercall for use with pv-ops kernels

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 10/10/13 16:45, Daniel Kiper wrote:
> On Wed, Oct 09, 2013 at 05:03:22PM +0100, David Vrabel wrote:
>> On 09/10/13 16:26, Daniel Kiper wrote:
>>> 
>>> What about setting GPRs to known value (e.g. 0 like in Linux Kernel)
>>> before jumping into purgatory?
>>
>> I have (repeatedly) explained why and you have not provided a sensible
> 
> What do you mean by that? I have not seen any real explanation.
> You were saying only that I am defining an ABI. I do not buy it.
> Even you did not reply to my last question: Could you tell me
> where do you see an ABI here?

I'm going to comment on your points one final time. I am not going to
debate with you any further on any of this.

The register state on executing the image is undefined (this is the
specified ABI), so there is no need to set the registers to any
particular value.

If the implementation did zero the registers then an image could rely on
this.  It would then be impossible to change the implementation to do
anything other than zero the registers as that would break existing
users.  Zeroing the register is thus an implicit or defacto ABI (even
though we specified the register values as undefined).

If the registers are not zeroed then it is highly unlikely that an image
could make use of their values and thus if we wish to change the
specification to set some register values we can safely do so without
breaking existing images.

>> reason why they should be zeroed.
> 
> OK, security reasons could be quite difficult to prove in that case and
> some may say that they are only theoretical here.

There is no security concern here.  The image must be fully trusted by
the host administrator since it has full access to all of the host's RAM
and devices.

If you're afraid an image might do something malicious then don't load
that image.

> However, why we do not care about compatiblity with existing implementation?

Xen does diverge from ABI provided by Linux where it makes sense.  i.e.,
where doing so makes for a better ABI or a better implementation.  For
example, 64-bit images are exec'd with page tables that only cover the
image segments (unlike on Linux were the page tables cover all of RAM
which has problems as noted by Jan with cachable mapping overlapping
with uncachable regions).

Compatibility with existing Linux tools is a nice bonus but should not
and does not constrain the Xen ABI or implementation.

> Are we going to write special purgatory
> code for Xen if one day original purgatory require 0 or another known value
> in one or more registers?

If that happens we can always revist the Xen implementation and consider
changing or (or just fix purgatory).

>>> By the way, you do not need to save and restore %rdi, %rsi and %rbx
>>> in relocate_pages() in xen/arch/x86/x86_64/kexec_reloc.S.
>>
>> This is done so relocate_pages() behaves like a proper function with the
>> standard calling convention.
> 
> If you would like to be inline with GCC (and a few others) calling convetion
> then you should save %rbx in relocate_pages() only. %rcx, %rdi and %rsi should
> be saved by caller if needed.

Yes, I got that wrong, but you're really into trivial nit-picking here
which is quite frankly neither helpful nor productive.

> Anyway, I do not care about saving registers not
> used later in relocate_pages() or around it.

This is stupid -- relocate_pages() is called like a function so it
should behave like one.  Anything else is going to trip up someone else
looking at or modifying the code in the future.

David

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