qemu-cris segfaults upon loading userspace binary
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I am on commit 65a3c5984074313
I'm trying to run a userspace CRIS binary (`./qemu-cris -cpu crisv10 ./basic`), but this segfaults. When opening the coredump in gdb, I get
gdb-peda$ bt
#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6
#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000,
prot=0x3) at ../linux-
#2 0x0000564a2f7bff65 in load_elf_image (
image_
info=
bprm_
at ../linux-
#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f
info=
#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3,
filename=
envp=
bprm=
#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f5
envp=
#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6
#7 0x0000564a2f786cee in _start ()
Or as a full backtrace:
gdb-peda$ bt full
#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6
No symbol table info available.
#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000,
prot=0x3) at ../linux-
host_start = 0x92134
host_end = 0x94000
#2 0x0000564a2f7bff65 in load_elf_image (
image_
info=
bprm_
at ../linux-
vaddr = 0x82134
vaddr_em = 0x82140
vaddr_len = 0x2000
vaddr_po = 0x134
vaddr_ps = 0x82000
vaddr_ef = 0x82134
elf_prot = 0x3
eppnt = 0x7fffe9f54974
ehdr = 0x7fffe9f54920
phdr = 0x7fffe9f54954
load_addr = 0x80000
load_bias = 0x0
loaddr = 0x80000
hiaddr = 0x1082140
error = 0x80000
i = 0x1
retval = 0x273d2e9c
prot_exec = 0x4
err = 0x0
__func__ = "load_elf_image"
#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f
info=
interp_info = {
load_bias = 0x0,
load_addr = 0x0,
end_code = 0x0,
end_data = 0x0,
start_brk = 0x0,
brk = 0x0,
entry = 0x0,
auxv_len = 0x0,
arg_start = 0x0,
arg_end = 0x0,
elf_flags = 0x0,
alignment = 0x0,
nsegs = 0x0,
loadsegs = 0x0,
}
elf_ex = {
e_ident = "|\214\
e_type = 0x8c7c,
e_machine = 0x3109,
e_version = 0x0,
e_entry = 0x5fee02b2,
e_phoff = 0x0,
e_shoff = 0x31098c7c,
e_flags = 0x0,
e_ehsize = 0x0,
e_phnum = 0x0,
e_shnum = 0x0,
}
scratch = 0x7f272a358021 <read+97> "H\213D$
#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3,
filename=
envp=
bprm=
retval = 0x400
#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f5
envp=
regs1 = {
orig_r10 = 0x0,
r0 = 0x0,
r1 = 0x0,
r2 = 0x0,
r3 = 0x0,
r4 = 0x0,
r5 = 0x0,
r6 = 0x0,
r7 = 0x0,
r8 = 0x0,
r9 = 0x0,
r10 = 0x0,
r11 = 0x0,
r12 = 0x0,
r13 = 0x0,
acr = 0x0,
srs = 0x0,
mof = 0x0,
spc = 0x0,
ccs = 0x0,
srp = 0x0,
erp = 0x0,
exs = 0x0,
eda = 0x0
}
regs = 0x7fffe9f54860
info1 = {
load_bias = 0x0,
load_addr = 0x80000,
end_code = 0x80133,
end_data = 0x0,
start_brk = 0x0,
brk = 0x80133,
entry = 0x80106,
auxv_len = 0x0,
arg_start = 0x0,
arg_end = 0x0,
elf_flags = 0x0,
alignment = 0x2000,
nsegs = 0x2,
loadsegs = 0x0,
}
info = 0x7fffe9f547c0
bprm = {
buf = "\177ELF\
p = 0x0,
fd = 0x3,
e_uid = 0x3e8,
e_gid = 0x3d9,
argc = 0x1,
envc = 0x43,
argv = 0x564a2f9f3cc0,
envp = 0x564a2fa12600,
filename = 0x7fffe9f5703d "./basic",
core_dump = 0x0
}
ts = 0x564a2fa25400
env = 0x564a2fa24a08
cpu = 0x564a2fa1c730
optind = 0x3
wrk = 0x7fffe9f550b8
target_argv = 0x564a2f9f3cc0
target_argc = 0x1
i = 0x1
ret = 0x7fff
execfd = 0x3
log_mask = 0x0
#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#7 0x0000564a2f786cee in _start ()
No symbol table info available.
The binary itself is just a basic binary that prints "hello\n" to stdout. I have attached it.
Sounds like it's probably the bug where we don't correctly handle ELF BSS segments which have no content in the file at all (ie they're just "zero this memory" with no content). If so, this patch (currently in review) will fix it:
https://<email address hidden>/
and you could also work around it by making sure your guest binary has some r/w data so it doesn't have a segment that's purely BSS.