
Memory Security in Go - libeclipse
https://cryptolosophy.io/memory-security-go/
======
wahern

      [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.

