Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754209AbdHYBKg (ORCPT ); Thu, 24 Aug 2017 21:10:36 -0400 Received: from mail-pg0-f47.google.com ([74.125.83.47]:38515 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753456AbdHYBKf (ORCPT ); Thu, 24 Aug 2017 21:10:35 -0400 Date: Fri, 25 Aug 2017 10:10:23 +0900 From: AKASHI Takahiro To: Ard Biesheuvel Cc: Catalin Marinas , Will Deacon , Thiago Jung Bauermann , David Howells , Vivek Goyal , Herbert Xu , "David S. Miller" , Andrew Morton , Michael Ellerman , Dave Young , Baoquan He , Arnd Bergmann , "kexec@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 08/14] arm64: kexec_file: create purgatory Message-ID: <20170825011022.GA7245@akashi-kouhiroshi-no-MacBook-Air.local> Mail-Followup-To: AKASHI Takahiro , Ard Biesheuvel , Catalin Marinas , Will Deacon , Thiago Jung Bauermann , David Howells , Vivek Goyal , Herbert Xu , "David S. Miller" , Andrew Morton , Michael Ellerman , Dave Young , Baoquan He , Arnd Bergmann , "kexec@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" References: <20170824081811.19299-1-takahiro.akashi@linaro.org> <20170824081811.19299-9-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1183 Lines: 27 On Thu, Aug 24, 2017 at 10:10:37AM +0100, Ard Biesheuvel wrote: > On 24 August 2017 at 09:18, 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. > > 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