[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170825011022.GA7245@akashi-kouhiroshi-no-MacBook-Air.local>
Date: Fri, 25 Aug 2017 10:10:23 +0900
From: AKASHI Takahiro <takahiro.akashi@...aro.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>,
David Howells <dhowells@...hat.com>,
Vivek Goyal <vgoyal@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Michael Ellerman <mpe@...erman.id.au>,
Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 08/14] arm64: kexec_file: create purgatory
On Thu, Aug 24, 2017 at 10:10:37AM +0100, Ard Biesheuvel wrote:
> On 24 August 2017 at 09:18, AKASHI Takahiro <takahiro.akashi@...aro.org> 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.
>
> This sounds fragile to me. What is the reason we cannot let the linker
> deal with this, similar to, e.g., how the VDSO gets linked?
Please note this is exactly what x86 code does.
I guess that the reason is that x86 guys borrowed the logic directly
from kexec-tools.
> Otherwise, couldn't we reuse the module loader to get these objects
> relocated in memory? I'm sure there are differences that would require
> some changes there, but implementing all of this again sounds like
> overkill to me.
I'll look at both of your suggestions.
Thanks,
-Takahiro AKASHI
Powered by blists - more mailing lists