On Mon, 3 Dec 2018, Claus Assmann wrote: > Here's the dissambler output and the ktrace output follows. > Unfortunately I don't know enough about this to figure out > what is wrong, hopefully someone else can (or tell me which > other information is still needed). TIA!
A close read of the ktrace output points to the problem: ... > 65554 server GIO fd 2 wrote 89 bytes > "[03/Dec/2018:08:28:29] INFO: process 0 (pid 65554): starting 8 > threads on localhost:1234 > " So it's just about to create its eight (userspace) threads... > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21771804393472/0x13cd24aac000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21771451404288/0x13cd0fa09000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21773345935360/0x13cd808cd000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21774756491264/0x13cdd4a03000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21774604423168/0x13cdcb8fd000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21773142749184/0x13cd74707000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21773994246144/0x13cda7314000 > 65554 server CALL > mmap(0,0x12000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) > 65554 server RET mmap 21774606540800/0x13cdcbb02000 Eight mmaps, presumably one per thread... > 65554 server CALL kbind(0x7f7ffffd4fa8,24,0x8a4abe18ba78cb4a) > 65554 server RET kbind 0 Okay, so this kbind() is by the original thread. The first argument to kbind() happens to be a buffer which is always on the current thread's stack. All is good here. ... > 65554 server CALL kbind(0x13cd24abcc48,24,0x8a4abe18ba78cb4a) > 65554 server PSIG SIGSEGV SIG_DFL addr=0x0 trapno=0 > 65554 server NAMI "server.core" And now this kbind() call blows up: the address is not on the original thread's stack but in one of those mmap()s...but those mmap()s were not marked as stacks by including MAP_STACK. To quote the "Security improvements" section of https://www.openbsd.org/64.html * Implemented MAP_STACK option for mmap(2). At pagefaults and syscalls the kernel will check that the stack pointer points to MAP_STACK memory, which mitigates against attacks using stack pivots. To confirm, if you check your dmesg(8) or /var/log/messages you should find the kernel complaining something like syscall [server]65554/### sp 13cd24a## not inside 0x7f7f###-0x7f7f### Philip Guenther
