UML kernel panic on initialization

[Anton Ivanov]

On 13/07/2021 05:04, YiFei Zhu wrote:
> On Mon, Jul 12, 2021 at 1:19 PM <subashab at codeaurora.org> wrote:
>> The start of instructions is at af0 for me -
>>
>> Disassembly of section .text:
>>
>> 0000000000000af0 <_dl_rtld_di_serinfo-0x7b10>:
>>        af0:       48 89 e7                mov    %rsp,%rdi
>>
>> The offset at af0 from start is -
>>
>>       15e0:       48 8d 35 79 97 01 00    lea    0x19779(%rip),%rsi
>> # 1ad60 <calloc+0x56e0>
> Interesting. I was expecting (from my ld-2.31.so) the initial ELF
> header to be in an initial non-executable page, and .text to be in a
> second page. Could you dump the segment headers with `readelf -lW
> ld-2.13.so`?
>
> Though, considering that:
> * the address of the start of .text matches exactly with the expected
> offset from the page where the faulting instruction is (40000af0)
> * UML doesn't have ASLR so 40000000 is probably where the loader is
> mapped into memory
> * my ld-2.31.so has its entry point address as 0x1100 and that is also
> the start of .text (PLT/GOT precedes it hence the 0x100 offset from
> page start)
> I'm pretty confident that 40000af0 was the entry point of the dynamic
> loader after it's mapped into memory (with the ELF entry point address
> as 0xaf0, you can check with `readelf -h ld-2.13.so`).
>
> If that is the case, then this faulting instruction is the first
> instruction executed in UML userspace, and the instruction is `mov
> %rsp,%rdi`. This instruction should not normally fail. The only common
> reason I can think of is the userspace's page isn't mapped properly
> somehow; either it's not mapped at all or it's not mapped executable.
>
>> Here is the output of the /proc/[pid]/maps -
>>
>> 60000000-60719000 rwxp 00000000 103:00 12718929
>> <full_path_to_linux_binary>
>> 60719000-6077b000 rwxp 00000000 00:00 0
>> [heap]
> Uhh... this is a UML kernel process. UML clones into many threads /
> processes, and each userspace task (inside UML) is a separate UML
> userspace process on the host (so as to isolate their address spaces,
> hence different VSZ from kernel). The UML userspace processes should
> not map the UML binary on the host, but rather lots and lots of
> /dev/shm/#8 maps (/dev/shm/#8 is UML's "physical memory").
>
> Since UML userspace dies almost immediately due to the segfault, you
> probably want to stop it from being killed by UML kernel upon segfault
> so you have a longer time window to look at the maps. What I would
> probably do is to add an infinite loop where the kernel printk the
> segfault information, in arch/um/kernel/trap.c, show_segv_info.
>
>> I don't know how to get VSZ from the maps output, so I used ps instead.
>> The value is 536932.
>>
> By the way, I compiled UML 5.13.1 with defconfig, with
>
>    make -j4 ARCH=um SUBARCH=x86_64 CROSS_COMPILE=
>
> and
>
>    ./linux mem=512M root=none rootfstype=hostfs rootflags=/ ro
> console=tty init=/bin/sh
>
> Cannot reproduce this error. To make sure it's not related to config,
> does the panic still occur if you use defconfig?

Same here. I cannot reproduce the error. I use the debian config for 64 with vde disabled for most of my tests.

Can we have your .config please?

A.

>
> YiFei Zhu
>
-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/