kernel panic when running Go program

[dvyukov]

While experimenting with akaros I've tried to run a Go program
compiled to linux and it caused kernel panic. I understand that that's
not the way I build programs for akaros, but it still should not cause
kernel panics I guess.

bash-4.3$ ./testgo
kernel warning at kern/src/syscall.c:2802, from core 0: Only one
supported (Debutante calls: 5438792)

HW TRAP frame at 0xfffffff0000a0e60 on core 0
  rax  0x0000000000000000
  rbx  0x0000000000001002
  rcx  0xffff8001015e0e10
  rdx  0xffff8001015e0e10
  rbp  0xfffffff0000a0f78
  rsi  0x0000000000000780
  rdi  0x0000000000001002
  r8   0xffff8000000b8fa0
  r9   0x0000000000000f00
  r10  0xffff8000000b8f00
  r11  0xffff8000000b8ec0
  r12  0x000000000052fd48
  r13  0xffff8001015e0e10
  r14  0x0000000000000000
  r15  0xffff8001001b3700
  trap 0x0000000e Page Fault
  gsbs 0xffffffffc82c8940
  fsbs 0x0000000000000000
  err  0x--------00000000
  rip  0xffffffffc2055308
  cs   0x------------0008
  flag 0x0000000000010246
  rsp  0xfffffff0000a0f28
  ss   0x------------0010

Backtrace of kernel context on Core 0:
#01 [<0xffffffffc2055308>] in run_local_syscall
#02 [<0xffffffffc20a098a>] in sysenter_callwrapper
kernel panic at kern/arch/x86/trap.c:311, from core 0: Proc-ful Page
Fault in the Kernel at 0x0000000000001002!
``

akaros is on 6344ed04e307ba30df879d1d407b10a1b3236784.
go version devel +9735fcfce7 Mon Oct 2 09:57:23 2017 +0000 linux/amd64
Go program is:

```go
package main
import (
  "fmt"
)
func main() {
  fmt.Printf("Hello, Akaros!\n")
}

I built it on host for linux/amd64 and then tried to run on akaros.

[dvyukov]

From @brho:

Short version: we're still sorting out the best, full-proof way to
handle userspace passing bad pointers to the kernel for delicate
operations. ... this will happen for many Linux
binaries, due to the syscall/sysenter ABI difference.  On Akaros, the
first parameter to sysenter is a struct syscall pointer.

[dvyukov]

You mentioned "delicate operations", do I understand it correctly that this does not affect normal pointer arguments to syscalls. I mean when user-space uses proper ABI, but passes a bad pointer.

[brho]

In most cases, yes. Or rather, it should be. For instance, there are checks on the pointers to open's path argument. But some other calls aren't checked in all cases, but should be. For instance, write's buffer argument is checked for some filesystems, but not others. That's a bug.