From: Mark Rutland <mark.rutland@arm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
catalin.marinas@arm.com, will.deacon@arm.com,
bauerman@linux.vnet.ibm.com, dhowells@redhat.com,
vgoyal@redhat.com, herbert@gondor.apana.org.au,
davem@davemloft.net, akpm@linux-foundation.org,
mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com,
arnd@arndb.de, ard.biesheuvel@linaro.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 08/14] arm64: kexec_file: create purgatory
Date: Fri, 25 Aug 2017 11:22:50 +0100 [thread overview]
Message-ID: <20170825102250.GA3127@leverpostej> (raw)
In-Reply-To: <20170825010054.GC6434@akashi-kouhiroshi-no-MacBook-Air.local>
On Fri, Aug 25, 2017 at 10:00:59AM +0900, AKASHI Takahiro wrote:
> On Thu, Aug 24, 2017 at 05:56:17PM +0100, Mark Rutland wrote:
> > On Thu, Aug 24, 2017 at 05:18:05PM +0900, AKASHI Takahiro wrote:
> > > This is a basic purgtory, or a kind of glue code between the two kernel,
> > > for arm64. We will later add a feature of verifying a digest check against
> > > loaded memory segments.
> > >
> > > arch_kexec_apply_relocations_add() is responsible for re-linking any
> > > relative symbols in purgatory. Please note that the purgatory is not
> > > an executable, but a non-linked archive of binaries so relative symbols
> > > contained here must be resolved at kexec load time.
> > > Despite that arm64_kernel_start and arm64_dtb_addr are only such global
> > > variables now, arch_kexec_apply_relocations_add() can manage more various
> > > types of relocations.
> >
> > Why does the purgatory code need to be so complex?
> >
> > Why is it not possible to write this as position-independent asm?
>
> I don't get your point, but please note that these values are also
> re-written by the 1st kernel when it loads the 2nd kernel and so
> they must appear as globals.
My fear about complexity is that we must "re-link" the purgatory.
I don't understand why that has to be necessary. Surely we can have the
purgatory code be position independent, and store those globals in a
single struct purgatory_info that we can fill in from the host?
i.e. similar to what we do for values shared with the VDSO, where we
just poke vdso_data->field, no re-linking required.
Otherwise, why can't the purgatory code be written in assembly? AFAICT,
the only complex part is the hashing code, which I don't beleive is
strictly necessary.
[...]
> > > +/*
> > > + * Apply purgatory relocations.
> > > + *
> > > + * ehdr: Pointer to elf headers
> > > + * sechdrs: Pointer to section headers.
> > > + * relsec: section index of SHT_RELA section.
> > > + *
> > > + * Note:
> > > + * Currently R_AARCH64_ABS64, R_AARCH64_LD_PREL_LO19 and R_AARCH64_CALL26
> > > + * are the only types to be generated from purgatory code.
> >
> > Is this all that has been observed, or is this ensured somehow?
>
> It was observed by inserting a debug print message in this function,
> I'm not sure whether we can restrict only those three types.
If we have to perform linking, I don't think we can assume the above is
sufficient.
> > The arch_kexec_apply_relocations_add() function below duplicates a lot
> > of logic that already exists in the arm64 module loader's
> > apply_relocate_add() function.
> >
> > Please reuse that code. Having a duplicate or alternative implementation
> > is just asking for subtle bugs.
>
> Okey, I'll look at it.
Ok.
As above, I think it would be preferable that we avoid linking entirely.
Thanks,
Mark.
next prev parent reply other threads:[~2017-08-25 10:24 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 8:17 [PATCH 00/14] arm64: kexec: add kexec_file_load support AKASHI Takahiro
2017-08-24 8:17 ` [PATCH 01/14] MODSIGN: Export module signature definitions AKASHI Takahiro
2017-08-24 8:17 ` [PATCH 02/14] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2017-08-24 9:04 ` Ard Biesheuvel
2017-08-24 8:18 ` [PATCH 03/14] resource: add walk_system_ram_res_rev() AKASHI Takahiro
2017-08-24 9:06 ` Ard Biesheuvel
2017-08-25 0:50 ` AKASHI Takahiro
2017-08-31 2:34 ` Pratyush Anand
2017-09-08 2:33 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 04/14] kexec_file: factor out vmlinux (elf) parser from powerpc AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 05/14] kexec_file: factor out crashdump elf header function from x86 AKASHI Takahiro
2017-08-25 5:47 ` Dave Young
2017-09-08 2:31 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 06/14] kexec_file: add kexec_add_segment() AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 07/14] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2017-08-24 10:53 ` Arnd Bergmann
2017-08-24 8:18 ` [PATCH 08/14] arm64: kexec_file: create purgatory AKASHI Takahiro
2017-08-24 9:10 ` Ard Biesheuvel
2017-08-25 1:10 ` AKASHI Takahiro
2017-08-24 16:56 ` Mark Rutland
2017-08-25 1:00 ` AKASHI Takahiro
2017-08-25 10:22 ` Mark Rutland [this message]
2017-08-25 16:16 ` Thiago Jung Bauermann
2017-09-08 2:46 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 09/14] arm64: kexec_file: add sha256 digest check in purgatory AKASHI Takahiro
2017-08-24 9:13 ` Ard Biesheuvel
2017-08-25 1:25 ` AKASHI Takahiro
2017-08-24 17:04 ` Mark Rutland
2017-08-25 1:21 ` AKASHI Takahiro
2017-08-25 10:41 ` Mark Rutland
2017-09-08 2:50 ` AKASHI Takahiro
2017-09-08 15:59 ` Thiago Jung Bauermann
2017-08-24 8:18 ` [PATCH 10/14] arm64: kexec_file: load initrd, device-tree and purgatory segments AKASHI Takahiro
2017-08-24 17:11 ` Mark Rutland
2017-08-25 1:34 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 11/14] arm64: kexec_file: set up for crash dump adding elf core header AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 12/14] arm64: enable KEXEC_FILE config AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 13/14] arm64: kexec_file: add Image format support AKASHI Takahiro
2017-08-24 17:23 ` Mark Rutland
2017-08-25 1:49 ` AKASHI Takahiro
2017-08-24 8:18 ` [PATCH 14/14] arm64: kexec_file: add vmlinux " AKASHI Takahiro
2017-08-24 17:30 ` Mark Rutland
2017-08-25 2:03 ` AKASHI Takahiro
2017-08-25 6:13 ` Dave Young
2017-09-08 2:54 ` AKASHI Takahiro
2017-08-29 10:01 ` Mark Rutland
2017-08-29 16:15 ` Thiago Jung Bauermann
2017-08-30 8:40 ` Michael Ellerman
2017-09-08 3:07 ` AKASHI Takahiro
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=20170825102250.GA3127@leverpostej \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dyoung@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=takahiro.akashi@linaro.org \
--cc=vgoyal@redhat.com \
--cc=will.deacon@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).