cmd/go: default to -buildmode=pie on Windows

[zx2c4]

It's 2019. ASLR has been well supported in Windows for a while. We should enable this by default or all the time and address any weird Go bugs that come up as a result. So far I haven't seen any.

ARM on Windows has had ASLR since its inception, so I imagine things are probably fine.

Personally, I'd prefer only allowing ASLR and not having the option in there to avoid it. I think that'd make things a bit simpler and less confusing too, a la v1 of the aslr cl: https://go.googlesource.com/go/+/c04035be04c3a0ef0e44c1e3674485048df5d327%5E%21/

CC @alexbrainman @ianlancetaylor @bradfitz @FiloSottile

[gopherbot]

Change https://golang.org/cl/203606 mentions this issue: cmd/link: enable ASLR by default on Windows

[alexbrainman]

I would also like to add that this proposal assumes that #27144 is implemented as -buildmode=pie. So this current proposal is effectively means that -buildmode=pie will become default on Windows (as suggested by @ianlancetaylor at #27144 (comment)).

Alex

[FiloSottile]

I am not convinced by the idea of overloading -buildmode with fundamental security features. Compiling with -buildmode=exe is currently the default, so it's reasonable to expect it to be a no-op, not a security downgrade.

I think we should just turn on ASLR everywhere, becoming consistent with arm. Losing the distinction between -buildmode=exe and -buildmode=pie sounds much more natural than making -buildmode=exe a security switch: features move into default modes making explicit switches no-ops all the time.

If we are concerned about encountering bugs, I think we should go about it as we go about everything else: testing during the freeze, and making a GODEBUG (or equivalent) opt-out (or temporary opt-in). Likewise, if we need to make it possible to disable ASLR to debug, that sounds like it should be a scary, debug-branded ldflag, not -buildmode=exe. How necessary is it, though?

[zx2c4]

I am not convinced by the idea of overloading -buildmode with fundamental security features. Compiling with -buildmode=exe is currently the default, so it's reasonable to expect it to be a no-op, not a security downgrade.

I think we should just turn on ASLR everywhere, becoming consistent with arm. Losing the distinction between -buildmode=exe and -buildmode=pie sounds much more natural than making -buildmode=exe a security switch: features move into default modes making explicit switches no-ops all the time.

Fully agree.

If we are concerned about encountering bugs, I think we should go about it as we go about everything else: testing during the freeze, and making a GODEBUG (or equivalent) opt-out (or temporary opt-in). Likewise, if we need to make it possible to disable ASLR to debug, that sounds like it should be a scary, debug-branded ldflag, not -buildmode=exe. How necessary is it, though?

All the debuggers I use have no problem dynamically rebasing. Otherwise, how would I possibly debug any real world applications or reverse engineer stuff?

[ianlancetaylor]

Perhaps we should indeed make -buildmode=exe be a synonym for -buildmode=pie on Windows, but we still must have a way to generate a non-PIE binary. I have seen far too many cases where non-PIE executables are required, albeit on non-Windows systems. How should people select a non-PIE binary? This should not be a scary, debug-branded, flag. There are legitimate choices here. The added security of ASLR, which in my personal opinion is quite small for a language like Go, can be reasonably traded off against the costs of ASLR.

[aarzilli]

All the debuggers I use have no problem dynamically rebasing. Otherwise, how would I possibly debug any real world applications or reverse engineer stuff?

I guess I should point out that debug_frame is broken on macOS with buildmode=pie. I haven't checked the state of debug symbols on windows with buildmode=pie.

[zx2c4]

I have seen far too many cases where non-PIE executables are required, albeit on non-Windows systems.

Can you point out a Windows case where non-PIE executables are required? Seems like we should base this on real actual cases. With auditors mechanically searching for them and flagging them in reports, they have been moving toward extinction for a long time now.

[ianlancetaylor]

Let's please take the conservative approach here. We know how to generate a non-PIE. If we change the default to be PIE, I see no reason at all to make it hard to generate a non-PIE.

[alexbrainman]

I am not convinced by the idea of overloading -buildmode with fundamental security features.

I am not married to making -buildmode=pie default idea. If you have better suggestion I am fine with that. -buildmode=pie will not require us to add any new flags.

I think we should just turn on ASLR everywhere, becoming consistent with arm.

I doubt we have many windows-arm Go users. We don't even have windows-arm builder. So we should treat ASLR as completely new feature.

I haven't checked the state of debug symbols on windows with buildmode=pie.

I agree, we should make sure Delve works with ASLR enabled windows binaries. We might discover that "build non ASLR executable" flag will get handy with Delve. Thank you @aarzilli for reminding us about Delve.

Let's please take the conservative approach here. We know how to generate a non-PIE. If we change the default to be PIE, I see no reason at all to make it hard to generate a non-PIE.

I completely agree.

Alex

[aarzilli]

Out of curiosity, when was buildmode=pie support added to windows? It wasn't in Go 1.11 because I remember I couldn't test Delve with it but I can't find mention of it in either 1.12 or 1.13 release notes.