Memory Security in Go

  [The garbage-collector] goes around doing whatever it feels
  like doing; making a copy here; moving something around
  there; it’s a real pain from a security standpoint.

Just a nit, but Go's GC isn't a copying collector, and is unlikely to ever be. (Meta nit: whenever I read discussions of Go's GC, especially criticisms, I've noticed that people often conflate a copying collector with a generational collector. Not all generational collectors are copying collectors. For example, Lua 5.2 had a generational GC, but Lua doesn't do copying. And you can have a copying collector without a generational GC. But the so-called bump allocator optimization that is often implemented along with a generational GC requires a copying collector.)

   we decided to go with ... mmap(2) .. since the system-call
   is natively implemented, and that allowed us to avoid a
   dirty cgo solution.

I don't write Go code, but looking at the documentation it looks like you could have used syscall.RawSyscall if Go hadn't already provided a wrapper to mmap. The wrapper might even internally use RawSyscall.