Curious about fixed heap mappings

[Shawn Webb]

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: lat...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE

[Ian Lance Taylor]

On Sat, Sep 8, 2018 at 4:31 PM, Shawn Webb <shawn...@hardenedbsd.org> wrote:
>
> 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?

[ My apologies for the double reply; mail header was wrong somehow. ]

Well, -buildmode=pie does what it says and what is documented: it
gives you a position independent executable. But it's a fair point
that the current runtime always asks the kernel to place the heap at
the same address. I encourage you to open an issue rat
https://golang.org/issue equesting the runtime to add some randomness
to the heap location. Thanks.

Ian

[Shawn Webb]

On Sun, Sep 09, 2018 at 12:00:36PM -0400, Shawn Webb wrote:

> On Sun, Sep 09, 2018 at 04:01:30AM -0700, Ian Lance Taylor wrote:
> > On Sat, Sep 8, 2018 at 4:31 PM, Shawn Webb <shawn...@hardenedbsd.org> wrote:
> > >

> > > 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?
> >

> > Well, -buildmode=pie does what it says and what is documented: it
> > gives you a position independent executable. But it's a fair point
> > that the current runtime always asks the kernel to place the heap at
> > the same address. I encourage you to open an issue rat
> > https://golang.org/issue equesting the runtime to add some randomness
> > to the heap location. Thanks.
>

> Hey Ian,
>
> Thanks for the response! Yeah, PIE is successfully acheiving its goal:
> allowint the OS to apply ASLR to the PIE exec base. No issues there. I
> only mentioned PIE support to reflect how it seems the golang project
> is seeing the wisdom behind supporting ASLR.
>
> Thanks for the suggestion on opening an issue. I'll go ahead and do
> that. I hope that with time, the entire golang runtime can take
> advantage of ASLR, making the language and its environment that much
> safer.

Sorry for the double reply on my end as well. I did something weird
with my email client in an attempt to fix a typo.

[Shawn Webb]

I've submitted a feature request here:
https://github.com/golang/go/issues/27583