[PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.
Thiago Jung Bauermann
bauerman at linux.vnet.ibm.com
Mon Aug 22 20:01:15 PDT 2016
Am Dienstag, 16 August 2016, 16:52:54 schrieb Balbir Singh:
> On 16/08/16 09:25, Thiago Jung Bauermann wrote:
> > Am Montag, 15 August 2016, 17:46:34 schrieb Balbir Singh:
> >> On Thu, Aug 11, 2016 at 08:08:09PM -0300, Thiago Jung Bauermann wrote:
> >>> +/**
> >>> + * elf64_apply_relocate_add - apply 64 bit RELA relocations
> >>> + * @elf_info: Support information for the ELF binary being
> >
> > relocated.
> >
> >>> + * @strtab: String table for the associated symbol
> >
> > table.
> >
> >>> + * @symindex: Section header index for the associated
> >
> > symbol table.
> >
> >>> + * @relsec: Section header index for the relocations to
> >
> > apply.
> >
> >>> + * @obj_name: The name of the ELF binary, for information
> >
> > messages.
> >
> >>> + */
> >>> +int elf64_apply_relocate_add(const struct elf_info *elf_info,
> >>> + const char *strtab, unsigned int symindex,
> >>> + unsigned int relsec, const char *obj_name)
> >>> +{
> >>> + unsigned int i;
> >>> + Elf64_Shdr *sechdrs = elf_info->sechdrs;
> >>> + Elf64_Rela *rela = (void *)sechdrs[relsec].sh_addr;
> >>> + Elf64_Sym *sym;
> >>> + unsigned long *location;
> >>> + unsigned long value;
> >>> +
> >>
> >> For the relocatable kernel we expect only
> >>
> >> R_PPC64_RELATIVE
> >> R_PPC64_NONE
> >> R_PPC64_ADDR64
> >>
> >> In the future we can use this to check/assert the usage of this
> >> for the core kernel (vmlinux) when loaded.
> >>
> >> Did we check elf64_apply_relocate_add with zImage and vmlinux?
> >
> > kexec_file_load doesn't call call elf64_apply_relocate_add on the kernel
> > image, it only uses it to relocate the purgatory. So whether it is
> > loading a zImage or a vmlinux file, the function will work in the same
> > way since the purgatory binary is the same regardless of the kernel
> > image format.
> Thanks for clarifying.
>
> > For the same reason, as it currently stands kexec_file_load can't check
> > the relocation types used in the kernel image. But it is possible to
> > add such a check/assertion in kexec_elf_64.c:build_elf_exec_info if we
> > want.
> >
> > I tested kexec_file_load on both relocatable and non-relocatable vmlinux
> > and it works correctly.
> >
> > I hadn't tested with zImage yet. I just did, and I had two problems:
> >
> > 1. For some reason, it has an INTERP segment. This patch series doesn't
> > support loading program interpreters for ELF binaries, so
> > kexec_elf_64.c:build_elf_exec_info refuses to load them.
> >
> > 2. If I disable the check for the INTERP segment, the zImage file loads
> > correctly, but then I get an exception during reboot when loading the
> > kexec image, right before jumping into the purgatory. I suspect this is
> > because the LOAD segment has a virtual address of 0, and the first
> > kernel is not coping well with that. But I still have to debug it
> > further.
> >
> > Is there a reason for the zImage ELF header to request an interpreter
> > and to have a virtual address of 0?
>
> Not that I am aware of.
zImage on ppc64 BE is an ELF32 file. This patch set only supports loading
ELF files of the same class as the kernel, so a 64 bit kernel can't load an
ELF32 file. It would be possible to add such support, but it would be a new
feature.
The distros I was able to check on ppc64 LE and BE all use vmlinux.
kexec-tools with kexec_load also doesn't support zImage. Do you think it is
important to support zImage?
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
More information about the kexec
mailing list