Re: Make kernel DWARF unwinder work with ksalr.

[Torsten Polle <Torsten dot Polle at gmx dot de>]

Hi Mark,

> Am 22.04.2018 um 23:09 schrieb Mark Wielaard <mark@klomp.org>:
> 
> Hi Torsten,
> 
> On Sun, 2018-04-22 at 10:52 +0200, Torsten Polle wrote:
>> I noticed that you made a similar commit
>> (17ee540dd61113fe4f557f191db3480db875cca1)
>> to the one I proposed in [1].
> 
> O, too bad I missed that thread. It would have saved me lots of time
> figuring out what was going on. Your observation in the last email is
> very true "The reason is that the backtrace operation has so many
> failsafe paths that it works most of the time. ;-)"
> 
>> The only difference is that you leave out the alignment of s->static_addr.
>> s->static_addr is equal to „_stext“, which is 0xc9600358 on my test instance.
>> While s->sec_load_offset is aligned to 0xc1000000 in a particular run. This
>> results in a misaligned offset. While on X86 and ARM64, the offset is aligned.
>> Without the alignment, I get strange results.
>> 
>> Arguably I choose a hard coded value 0x1fffff. Actually it should be based on
>> CONFIG_PHYSICAL_ALIGN on X86, but on ARM64 it is hard coded as well.
> 
> On my system it is 0x200000 and it looks like sec_load_offset is
> already aligned to that, which explains why it seems to work for me.

sec_load_offset is aligned to 0x200000. The problem is the „misalignment" of static_addr, which results in an offset that is not aligned. The problem is also difficult to spot. As a lot of results show nice call stacks.

With my patch I get the correct call stack
i386_start_kernel
start_kernel
rest_init
cpu_startup_entry
default_idle_call
arch_cpu_idle
default_idle
native_safe_halt

With your call stack the result is as follows.
unknown
cpu_startup_entry
default_idle_call
arch_cpu_idle
default_idle
native_safe_halt

The call stack calculation stops prematurly and the top most function
cannot be resolved.

> I can see CONFIG_PHYSICAL_ALIGN being used for x86 and powerpc, but not
> arm64, can you point at where it is used (or hard-coded)?

I use the following kernel: 4.8.12-yocto-standard

arch/arm64/kernel/kaslr.c

u64 __init kaslr_early_init(u64 dt_phys, u64 modulo_offset)
{
	…

	/*
	 * OK, so we are proceeding with KASLR enabled. Calculate a suitable
	 * kernel image offset from the seed. Let's place the kernel in the
	 * lower half of the VMALLOC area (VA_BITS - 2).
	 * Even if we could randomize at page granularity for 16k and 64k pages,
	 * let's always round to 2 MB so we don't interfere with the ability to
	 * map using contiguous PTEs
	 */
	mask = ((1UL << (VA_BITS - 2)) - 1) & ~(SZ_2M - 1);
	offset = seed & mask;
}

IMHO SZ_2M - 1 is the hard coded value.

> Thanks,
> Mark

Kind Regards,
Torsten