[CRIU] [PATCH 3/4] vdso: Rework vdso processing files

[Christopher Covington]

On 09/15/2015 11:56 AM, Laurent Dufour wrote:
> On 15/09/2015 17:38, Christopher Covington wrote:
>> On 09/15/2015 11:14 AM, Laurent Dufour wrote:
>>> On 15/09/2015 17:01, Christopher Covington wrote:
>>>> On 09/15/2015 09:54 AM, Christopher Covington wrote:
>>>>
>>>>>> -int vdso_fill_symtable(char *mem, size_t size, struct vdso_symtable *t)
>>>>>> -{
>>>>>> -	Elf64_Phdr *dynamic = NULL, *load = NULL;
>>>>>> -	Elf64_Ehdr *ehdr = (void *)mem;
>>>>>> -	Elf64_Dyn *dyn_strtab = NULL;
>>>>>> -	Elf64_Dyn *dyn_symtab = NULL;
>>>>>> -	Elf64_Dyn *dyn_strsz = NULL;
>>>>>> -	Elf64_Dyn *dyn_syment = NULL;
>>>>>> -	Elf64_Dyn *dyn_hash = NULL;
>>>>>> -	Elf64_Word *hash = NULL;
>>>>>> -	Elf64_Phdr *phdr;
>>>>>> -	Elf64_Dyn *d;
>>>>>> -
>>>>>> -	Elf64_Word *bucket, *chain;
>>>>>> -	Elf64_Word nbucket, nchain;
>>>>>> -
>>>>>> -	/*
>>>>>> -	 * See Elf specification for this magic values.
>>>>>> -	 */
>>>>>> -	const char elf_ident[] = {
>>>>>> -		0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x00,
>>>>>> -		0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>>>>> -	};
>>>>>> -
>>>>>> -	const char *vdso_symbols[VDSO_SYMBOL_MAX] = {
>>>>>> -		[VDSO_SYMBOL_CLOCK_GETRES]	= VDSO_SYMBOL_CLOCK_GETRES_NAME,
>>>>>> -		[VDSO_SYMBOL_CLOCK_GETTIME]	= VDSO_SYMBOL_CLOCK_GETTIME_NAME,
>>>>>> -		[VDSO_SYMBOL_GETTIMEOFDAY]	= VDSO_SYMBOL_GETTIMEOFDAY_NAME,
>>>>>> -		[VDSO_SYMBOL_RT_SIGRETURN]	= VDSO_SYMBOL_RT_SIGRETURN_NAME,
>>>>>> -	};
>>>>
>>>> It looks like making vdso_symbols global was the problem. Any objections to
>>>> moving the definition (the version that uses architecture-provided macro
>>>> ARCH_VDSO_SYMBOLS) inside the vdso_fill_symtable function?
>>>
>>> The main objection here is the stack's usage, but this table is not so
>>> big so...
>>
>> On this point, it's const, so I didn't expect it to be allocated on the stack.
> 
> So if it is not allocated on the stack, it will put in the data (or
> code) area like the original declaration, what's the change ?
>
>>> Anyway, my fear here is that this hiding a more complex issue relative
>>> to the PIE's code and the underlying relocation. Isn't it ?
>>
>> That could be.
> 
> I got similar issue before the relocation was in place in the parasite
> code. May be this is the same case here. May be you should have a look
> to that part for aarch64 ?

I've patched my kernel so that your vdso_remap.c test case passes, but that
doesn't fix this issue. I'm thinking the best debug strategy for me is to
fiddle with some minimal test cases, one where the array is global, and one
where it's got function scope, and look closely at the objdump and maybe some
instruction traces to understand the generated assembly and why one works and
the other doesn't under. My naive expectation is that when one passes
aarch64-linux-gnu-gcc the -pie flag, all address calculations are done in a
PC-relative manner, but perhaps there are limitations on what can be made
PC-relative, or there are toolchain bugs, or there are extra flags that need
to be provided.

Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project