linux-kernel - Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ca4a2de-0d44-dbc6-b57b-c149d10b048f@gmail.com>
Date:	Tue, 16 Aug 2016 16:52:54 +1000
From:	Balbir Singh <bsingharora@...il.com>
To:	Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>
Cc:	kexec@...ts.infradead.org,
	Stewart Smith <stewart@...ux.vnet.ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Baoquan He <bhe@...hat.com>, linuxppc-dev@...ts.ozlabs.org,
	x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Eric Biederman <ebiederm@...ssion.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dave Young <dyoung@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH v5 04/13] powerpc: Factor out relocation code from
 module_64.c to elf_util_64.c.



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. 

Balbir Singh