From: ebiederm@xmission.com (Eric W. Biederman)
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: hbabu@us.ibm.com, hpa@linux.intel.com, keescook@chromium.org,
vgoyal@redhat.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, david.vrabel@citrix.com,
jbeulich@suse.com, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: kexec: Clearing registers just before jumping into purgatory
Date: Fri, 11 Oct 2013 15:15:38 -0700 [thread overview]
Message-ID: <877gdjbgj9.fsf@xmission.com> (raw)
In-Reply-To: <20131011110455.GA3626@debian70-amd64.local.net-space.pl> (Daniel Kiper's message of "Fri, 11 Oct 2013 13:04:55 +0200")
Daniel Kiper <daniel.kiper@oracle.com> writes:
> On Fri, Oct 11, 2013 at 03:08:43AM -0700, ebiederm@xmission.com wrote:
>> Daniel Kiper <daniel.kiper@oracle.com> writes:
>>
>> > Hi,
>> >
>> > Could you explain why do you clear all registers just before jumping
>> > into purgatory (please look into arch/x86/kernel/relocate_kernel_64.S
>> > for more details)? There is no any single word about that. I do not
>> > count comment which states what is going on. purgatory on entry does
>> > not assume any value in registers. Are you going to use that feature
>> > for something in the future (e.g. to differentiate between callers
>> > and/or Linux versions if it be needed)?
>>
>> It has been a long time now, but as I recall the reason was to just
>> have things well defined and to make certain that we were not
>> accidentially exporting anything except the stack pointer for
>> applications to depend upon.
>>
>> 0/NULL is a good choice because if you are expecting pointer for some
>> strange reason interesting things happen.
>
> This covers more or less with my expectations.
>
>> purgatory is definitely not the only target and the C version of
>> purgatory was actually written well after kexec came into existence.
>>
>> Is there any particular reason why you are asking?
>
> Yes, we (Xen guys) are discussing is it worth to do it or not in our
> kexec implementation. I think that yes because we used Linux Kernel
> kexec implementation as a base for our work and we use kexec-tools too.
> So we should be aligined to what currently is in the wild. David do not
> agree with me. You could find more here:
>
> http://lists.xen.org/archives/html/xen-devel/2013-10/msg00710.html
> http://lists.xen.org/archives/html/xen-devel/2013-10/msg00296.html
>
> What is your opinion in that case?
I can see documenting the registers other than the stack pointer
as undefined. (A stack pointer is needed to implement PIC code).
For the implementation I recommend setting these registers to known
values. The issue is that your implementation will not change much and
if you don't set the registers to known values someone may develop a
dependency on what you happen to have those registers set to.
It is easier to force a fixed value into a register that isn't hard to
maintain into your registers than to discover when you make a change
that there is some odd client that depends on some value that just
happened to be in your register, and that your necessary change is now
made 10x harder by a client you can't afford to break that depends on a
bug in the previous implementation.
So yes I strongly recommend setting the registers to a 0 in this case.
>> Something different is done, and all of the registers should be
>> preserved from the when the return to Linux.
>
> I expected that but purgatory does nothing with them.
> However, maybe I missed something.
Yes. I think I am mostly in the document that you can't depend on them,
but keep them fixed to prevent problematic dependencies creeping in
because something just works...
Eric
next prev parent reply other threads:[~2013-10-11 22:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 9:28 kexec: Clearing registers just before jumping into purgatory Daniel Kiper
2013-10-11 10:08 ` Eric W. Biederman
2013-10-11 11:04 ` Daniel Kiper
2013-10-11 12:52 ` Vivek Goyal
2013-10-11 15:37 ` Matthew Garrett
2013-10-11 15:44 ` Vivek Goyal
2013-10-11 15:48 ` Matthew Garrett
2013-10-11 16:33 ` Richard Weinberger
2013-10-11 16:39 ` Matthew Garrett
2013-10-11 16:42 ` Richard Weinberger
2013-10-11 16:44 ` Matthew Garrett
2013-10-11 16:47 ` Richard Weinberger
2013-10-11 16:55 ` Matthew Garrett
2013-10-11 16:59 ` Richard Weinberger
2013-10-11 17:01 ` Matthew Garrett
2013-10-11 20:44 ` Eric W. Biederman
2013-10-11 20:50 ` Matthew Garrett
2013-10-11 16:53 ` Vivek Goyal
2013-10-11 16:56 ` Matthew Garrett
2013-10-11 22:15 ` Eric W. Biederman [this message]
2013-10-14 18:24 ` Daniel Kiper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gdjbgj9.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=daniel.kiper@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=hbabu@us.ibm.com \
--cc=hpa@linux.intel.com \
--cc=jbeulich@suse.com \
--cc=keescook@chromium.org \
--cc=keir@xen.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox