Remove pie from GOFLAGS

[luhring]

We don't think this setting has a worthwhile benefit to the Go binaries we're building. cc: @joshrwolf @kaniini

[mattmoor]

I am curious about this because this feels like a security feature that let's the loader randomize the binary layout in memory.
We enable a variety of security flags in our C/C++ toolchain, so I'm curious why we think there isn't a benefit for Go?

I am also curious what this costs us in terms of downside to have on (I see a few comments about -race not working).

[luhring]

After consulting with my trusted companion, ChatGPT, I agree with @mattmoor that this is worth further thought.

Yes, there is a security benefit to using the -pie (Position Independent Executable) flag when building Go programs, or any other type of program for that matter.

Position Independent Executables (PIEs) are executables that can be loaded at any memory address without affecting the program's functionality. This makes it harder for attackers to exploit memory corruption vulnerabilities, such as buffer overflows or code injection attacks, as the exact memory addresses of critical functions and data are not known in advance.

By using the -pie flag during the compilation process, you enable the creation of Position Independent Executables. This flag tells the linker to generate an executable that can be loaded at any address in memory. It includes the necessary relocation information in the binary so that the operating system can adjust the memory addresses during runtime.

The benefits of using PIEs include:

1. Address Space Layout Randomization (ASLR): ASLR is a security technique that randomizes the memory layout of an executable, making it difficult for attackers to predict the location of critical functions and data. PIEs are a prerequisite for effective ASLR implementation.

2. Mitigation of memory corruption attacks: PIEs make it more challenging for attackers to exploit memory corruption vulnerabilities, as they cannot rely on fixed memory addresses for their malicious code or data.

3. Defense-in-depth: Using PIEs is an additional security measure that complements other security mechanisms like stack canaries, non-executable memory (NX), and Address Sanitizer (ASan). It adds an extra layer of protection to your executable.

While PIEs enhance security, it's important to note that they are not a silver bullet and do not guarantee complete protection against all types of attacks. They are just one piece of the security puzzle, and it's crucial to follow other best practices like proper input validation, secure coding techniques, and regular security audits to ensure the overall security of your Go programs.

[joshrwolf]

lifting this out of slack for future context:

the impetus for this change was -pie resulted in dynamically linked go binaries. we found this while dealing with the (sadly) many apps that like to mv/cp things around init-containers.

I agree with luhring that we probably overcorrected making -pie opt-in, and it's worth reconsidering.

there seem to be ways to have -pie and eat it too (static builds), which might be something we consider as well:

# https://stackoverflow.com/questions/64019336/go-compile-to-static-binary-with-pie
go build  -ldflags '-linkmode external -s -w -extldflags "--static-pie"' -buildmode=pie -tags 'osusergo,netgo,static_build' -o /hello hello.go

[kaniini]

We are likely to start building dynamic Go binaries for other reasons, namely using libcrypto for cryptography (so we can do a single build and support FIPS mode in the usual way).

[xnox]

@mattmoor @joshrwolf @luhring @kaniini

More recent golang toolchains have fixed -buildmode=pie to not trigger/require/pull-in cgo and do not trigger/require external linking. Thus enabling -buildmode=pie these days should retain binaries as is (static ones remain static, dynamic ones remain dynamic) without much cause of issues. On most platforms (see per-go version as to which platforms support internal PIE mode, and even default to it - mostly mobile phone targets).

In terms of benefits - I cannot find evidence of what benefits this brings to statically linked binaries (i.e. pure-go ones, or those that disable CGO). It will pacify binary scanners that flag up these binaries as not having PIE.

For the FIPS builds, this will bring benefits, as we do have CGO enabled there, they are dynamically linked with C code, and they do call out to libcrypto.so (c code).

I don't know what the penalty/difference this makes to the static binaries, and if it is worth turning this on by default, even if it doesn't bring any obvious advantages to the statically linked go binaires.