最直接方法是用syzkaller：它用Go编写，通过.sys描述语言自动生成系统调用序列，在启用CONFIG_KCOV的内核中运行于QEMU，生成C测试程序并捕获崩溃；无需手写汇编或C封装。
用 syzkaller 生成系统调用序列最直接
Go语言本身不提供系统调用模糊测试能力，但 syzkaller 是专为 Linux 内核设计的、用 Go 编写的系统调用模糊器，它能自动生成合法/非法的系统调用组合，在虚拟机中反复执行并捕获崩溃或异常行为。
关键点在于：你不需要手写系统调用汇编或 C 封装，syzkaller 的描述语言（.sys 文件）定义了每个系统调用的参数类型、约束和依赖关系，Go 编译器会把它们转成可执行的测试程序。
- 必须用支持
KCOV的内核编译选项（CONFIG_KCOV=y），否则覆盖率反馈失效，模糊效果大幅下降 - QEMU 启动时需加
-kernel指向你编译好的带 KCOV 的内核镜像，不能只靠 initramfs 自带内核 -
syzkaller自身是 Go 程序，但生成的测试用例是纯 C 代码（通过syz-prog编译），所以虚拟机里不需要装 Go 运行时
在 QEMU 中跑 runsc 或 gVisor 能隔离系统调用行为
如果你不是想测内核，而是想验证自己的 Go 程序在受限环境里如何响应系统调用（比如被拦截、返回 ENOSYS、或走用户态模拟路径），runsc（gVisor 的 OCI 运行时）比裸机更可控。
它把所有系统调用拦截进 Go 编写的用户态内核，你可以用 strace -e trace=all 对比宿主机 vs gVisor 容器里的系统调用行为差异，快速发现哪些调用被跳过、重写或拒绝。
立即学习“go语言免费学习笔记（深入）”；
- 注意
runsc默认禁用部分系统调用（如clone、ptrace），启用需显式配置"sysctl": {"kernel.unprivileged_userns_clone": "1"} - gVisor 不支持所有 Linux ABI，例如某些
epoll变体或io_uring的高级 flag，Go 程序若用了会静默降级或 panic - 启动容器时加
--runtime=runsc和-v /path/to/go/binary:/app，再 exec 进去运行二进制，比改内核更轻量
用 cilium/ebpf + Go 实现运行时系统调用观测
如果目标是“自测”而非“模糊”，即你想知道自己的 Go 程序实际发出了哪些系统调用、参数是什么、耗时多久，cilium/ebpf 库配合 eBPF kprobe 是目前最精准的方式。
它不依赖 ptrace，不干扰程序执行流，且能在虚拟机里直接加载，只要内核版本 ≥ 5.8 并开启 BPF_SYSCALL 配置即可。
- 用
syscall.Syscall或unix.Syscall显式发起调用时，eBPF 可捕获；但 Go 运行时内部的调用（如epoll_wait、read）默认不暴露，需用tracepoint:syscalls:sys_enter_*全局监听 -
cilium/ebpf的Map.Lookup返回的是原始字节，需按struct pt_regs手动解析寄存器值（x86_64 下rax是 syscall number，rdi/rsi/rdx是前三个参数） - 别在 QEMU 的 BIOS 模式下加载 eBPF，确保用 UEFI 启动并启用
CONFIG_BPF_JIT=y，否则加载失败报错operation not permitted
Go 程序交叉编译到 Xen/AtmanOS 环境要改 CGO 和 sys/unix
若目标是 Xen 虚拟化层（比如 AtmanOS），Go 默认不支持 GOOS=atman —— 这个值不存在于标准 go/src/cmd/dist/build.go 的有效列表中。强行设置只会导致构建失败，报错 unknown operating system "atman"。
真正可行路径是：fork Go 标准库，修改 src/syscall 和 src/internal/syscall/unix，把 read/write 等调用转为 hypercall 接口，并重新编译整个工具链（包括 go 命令本身）。
- AtmanOS 的 hypercall ABI 与 Linux syscall ABI 不兼容，不能靠
CGO_ENABLED=0绕过，必须重写底层 stub -
GOARCH=amd64可保留，但GOOS必须注册进go/src/cmd/compile/internal/syntax/token.go的 osList - 这种修改属于深度定制，不适合日常自测；建议先用
qemu-system-x86_64 -bios OVMF.fd启动标准 Linux，再在上面跑 syzkaller 或 eBPF 工具
最容易被忽略的一点：所有这些方案都依赖虚拟机内核的调试能力开放程度。比如 KCOV、eBPF、hypercall 支持，都不是默认开启的——你得亲手改 .config、重编内核、验证模块加载成功，光靠 go build 是没用的。
