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
cmd/link: on Windows, generate dynamic base executables also on amd64 and x86 #27144
Comments
Change https://golang.org/cl/152759 mentions this issue: |
I'm assuming this is still unplanned, and not scheduled for 1.14? Is there anything I could do to help get this merged in, the CL looks very straightforward, I guess just the original submitter of the CL hasn't replied in months? |
When the trybots were run for the CL mentioned above, the CL failed on Windows systems. Somebody will need to debug that. |
I would like this implemented. And we don't need John to finish his CL. We could create a new CL. @capnspacehook, why do you want this change? How will you use it? The only issue is still bothering me. I think this change should be default, not hidden behind "never used during day to day work" flag. Otherwise people will never use this facility. On the other hand, having Go code always load at the same address is often useful when debugging. Perhaps we should make this default, and allow for some go command flag to make Go code use fixed addresses. John's CL selected to use /cc @zx2c4 for input. Thank you. Alex |
Indeed this should be turned on by default. Most debuggers and reverse engineering tools can rebase fine and figure stuff out. Recent versions of IDA Pro do this a lot faster than it used to be too. |
I am fine with that, if others do not object. @ianlancetaylor , if we want to make all Windows executables use random addresses ( https://en.wikipedia.org/wiki/Address_space_layout_randomization ) by default, do we need proposal here? Thank you. Alex |
It doesn't need a proposal, but I'm not sure it's the right thing to do. What do other compilers do? In particular, what do GCC and clang do? |
@alexbrainman I am really interested in the added security benefits of PIE windows executables; as you mentioned ASLR and inhibiting reverse engineering more. As for what to do, I agree that PIE mode for Windows executables should be default. But I think using the |
ASLR, yes. "Inhibiting reverse engineering" - what? |
Sorry, I just meant ASLR will make reverse engineering a bit more difficult, if I understand correctly. Now that I think about it, I think I got RE mixed up with binary exploitation... my bad |
I do not know about clang. But I tried Mingw GCC C, and Microsoft C and C#. According to https://stackoverflow.com/questions/8554014/how-to-know-whether-a-dll-uses-aslr-or-not GCC does not produce ASLR binaries by default:
But both Microsoft C and C# both generate ASLR by default:
Alex |
Took a bunch of flags to do it: https://git.zx2c4.com/wireguard-windows/diff/Makefile?id=7b6fcc0184e58626007b581be04ac7f5312861ea Using The result: |
I rebuilt a few of the musl.cc toolchains with this patch applied on top of the current musl.cc binutils
|
If GCC doesn't generate PIE by default, it's not obvious to me that go should. Clearly we should make sure that The question here is not whether PIE is more secure. It's what the default behavior should be. |
I don't think you should dismiss the fact that Microsoft compilers do generate PIE by default. Most Windows executables are built by Microsoft tools.
Sure, we could do that. But I don't see why Go developers would use this command option. ASLR is supposed to help make Windows more secure. Developers don't care about their users OS security. It is OS admin responsibility to make system secure. Developers will use whatever default build mode is. Also current windows-arm version of Go already uses PIE by default https://go-review.googlesource.com/c/go/+/125648 I think our current go command flags are just confusing in that area. Alex |
I can't see a compelling reason at all not to produce PIE executables for all Go users, vanilla and cgo, as the default option. Sure we can have a switch to disable PIE for the weird cases where people don't want it, but as @alexbrainman points out, PIE (and DEP, for that matter) is the default situation on Windows since a very long time. Differing from that and providing a less secure experience with Go out of the box is bad news. The fact that Go was producing 90s-style executables by default certainly caught me by surprise. |
Alright, WireGuard for Windows 0.0.35, just now released to users, enables DEP and high-entropy ASLR, on both amd64 and 386. I'll report back if anybody indicates awful breakage -- the largeish userbase is usually pretty reactive. I suspect things will be mostly okay. |
@alexbrainman Fair enough. Does anybody think it would be a bad idea to change the default to be PIE on Windows? Does anybody have a suggestion as to how it should work? Would we keep the current |
Probably the question of the default should be a separate issue. |
ARM does it unconditionally. What if we just did it that way? Or do you think providing the option is important? |
Change https://golang.org/cl/203602 mentions this issue: |
I think we should create new proposal for that, and see what happens. The only downside I see, we might discover some bugs.
That sounds good to me. As long as
I have an impression that we don't have choice for ARM. And I think it is important, that we have easy way to disable ASLR if required. I would use that myself while debugging. And, if we follow Ian's suggestion, it is just Alex |
AFAIK, Windows ARM bins have to be relocatable. And I think Ian's suggestion makes a lot of sense |
Done: #35192 |
This CL is now called "cmd/link: allow ASLR on Windows executables", and I've moved the default stuff to https://go-review.googlesource.com/c/go/+/203606 for discussion in #35192 . |
Change https://golang.org/cl/214397 mentions this issue: |
As part of windows/arm support, in CL125468
cmd/ld
has learnt how to generate dynamic base executables, that is binaries that can be relocated at any virtual memory address. This allows the Windows kernel to turn on ASLR.The support has been activated only on windows/arm. It should be activated also on amd64 and x86, so that Go binaries on Windows can benefit from ASLR.
/cc @alexbrainman
The text was updated successfully, but these errors were encountered: