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? > +/* > + * 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? 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. Thanks, Mark.
