-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: default to -buildmode=pie on Windows #35192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Change https://golang.org/cl/203606 mentions this issue: |
I would also like to add that this proposal assumes that #27144 is implemented as Alex |
I am not convinced by the idea of overloading I think we should just turn on ASLR everywhere, becoming consistent with arm. Losing the distinction between 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 |
Fully agree.
All the debuggers I use have no problem dynamically rebasing. Otherwise, how would I possibly debug any real world applications or reverse engineer stuff? |
Perhaps we should indeed make |
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. |
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. |
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 am not married to making
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 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.
I completely agree. Alex |
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. |
@aarzilli As far as I know |
In that case I don't understand how https://go-review.googlesource.com/c/go/+/203606 is passing trybots. |
Those CLs are changes to the linker to make it generate PIE. They don't add support for |
On various Android systems we already set the default buildmode to pie in cmd/go. @FiloSottile, I hear what you are saying, but this is an implementation mechanism and a security detail. I would argue it is not primarily about security. The bug says ASLR but really this is just about making a position-independent binary. There are other reasons to have one of those besides ASLR. Does anyone object to changing the default buildmode for Windows to pie in Go 1.15? |
Hasn't this been working for a while? I think 1.14 is a reasonable target, esp as it's a security improvement. There's the whole freeze period to turn up any problems. EDIT: sorry, got this mixed up with #27144 |
How about we will make If this suggestion is accepted, I ask for dispensation to implement #27144 after Go 1.14 freeze. It should not be hard to implement, but there are only few days left. Alex |
I think that's OK although it needs to be complete by the week after the freeze. |
It looks very much like -buildmode=pie will not be working, reviewed, and submitted by Friday, so we should hold off on implementation until next cycle. Sorry, but we are being extra strict about the freeze to try to make sure we spend November getting the beta ready, not doing more development. Given that it won't be in Go 1.14, assuming it is ready for the start of the Go 1.15 cycle, it seems fine, as I said last week, to implement -buildmode=pie and make that the default, in the same cycle. No one has objected to changing the default (once the code works), so this proposal seems like a likely accept. Leaving open for a week for final comments. |
Relevant CLs: https://golang.org/cl/203602 & https://golang.org/cl/203606 EDIT: Alas, the first is unfinished and the second turned out to be wrong :-( |
Accepted. |
Change https://golang.org/cl/214397 mentions this issue: |
This CL implements windows version of -buildmode=pie code in both cmd/go and cmd/link. Windows executables built with -buildmode=pie set (unlike the one built with -buildmode=exe) will have extra .reloc PE section, and will have no IMAGE_FILE_RELOCS_STRIPPED flag set. They will also have IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag set, and IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA flag set for windows/amd64. Both cgo and non-cgo versions are implemented. And TestBuildmodePIE is extended to test both cgo and non-cgo versions on windows and linux. This CL used some code from CLs 152759 and 203602. RELNOTE=yes Fixes #27144 Updates #35192 Change-Id: I1249e4ffbd79bd4277efefb56db321c390c0f76f Reviewed-on: https://go-review.googlesource.com/c/go/+/214397 Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
Change https://golang.org/cl/230217 mentions this issue: |
This change adjusts go command to pass -buildmode=pie to cmd/link, if -buildmode is not explicitly provided. Fixes golang#35192 Change-Id: Iec020131e676eb3e9a2df9eea1929b2af2b6df04 Reviewed-on: https://go-review.googlesource.com/c/go/+/230217 Run-TryBot: Alex Brainman <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
Since Go version 1.15 ASLR security mode is enabled by default for Windows builds. In order to make it work without random NPE crashes in the cores (as example in PSX games during load), you have to (re)compile every core with ASLR support or just disable this mode. See: golang/go#35192
Since Go version 1.15 ASLR security mode is enabled by default for Windows builds. In order to make it work without random NPE crashes in the cores (as example in PSX games during load), you have to (re)compile every core with ASLR support or just disable this mode. See: golang/go#35192
Since Go version 1.15 ASLR security mode is enabled by default for Windows builds. In order to make it work without random NPE crashes in the cores (as example in PSX games during load), you have to (re)compile every core with ASLR support or just disable this mode. See: golang/go#35192
Since Go version 1.15 ASLR security mode is enabled by default for Windows builds. In order to make it work without random NPE crashes in the cores (as example in PSX games during load), you have to (re)compile every core with ASLR support or just disable this mode. See: golang/go#35192
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
The text was updated successfully, but these errors were encountered: