Hey All, I've read through a previous discussion in 2012 about golang's use of deterministic memory allocations here: https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/qp2oyfEEfjQJ
Back then, -buildmode=pie didn't exist back then, so I figured a revisit of the topic might be warranted. Go 1.11 introduced -buildmode=pie for FreeBSD, which HardenedBSD is able to take advantage of, given HBSD's PaX ASLR implementation. HardenedBSD is a hardened derivative of FreeBSD. When applying -buildmode=pie with gitea, I wanted to verify that golang was able to take full advantage of HardenedBSD's robust ASLR implementation. I noticed a fixed mapping at 0xc000000000. I restarted the process, looked at the memory mappings again (`procstat -v $PID`) and saw 0xc000000000 again. Grepping through the golang 1.11 codebase revealed that Go allocates its heap at a fixed address, starting at 0xc000000000. With the heap being allocated at a fixed mapping, golang applications are still not able to really utilize ASLR. Thus, -buildmode=pie is ineffectual. Given that the reason to implement PIE support is to take advantage of ASLR, I'm curious if perhaps updating the heap management code for ASLR support was overlooked. Or perhaps it wasn't, and this is deliberate. Or perhaps a totally different reason. Either way, could someone shed some light on this? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
