2021-10-05 18:03:41     Seirdy  Hey, I noticed a certain Fedora issue I had was also visible in Alpine. It revolves around packaging Go programs and use of -buildmode=pie.
2021-10-05 18:03:41     Seirdy  I sent this to a Fedora list, but I think the bits that aren't RPM-specific should apply here: https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org/thread/PKV3RRMQUBZVGK7CYMKMM4VI2HHVNLDI/
2021-10-05 18:05:54     Seirdy  Essentially, both Fedora and Alpine use buildmode=pie when the Go runtime uses a fixed address regardless; buildmode=pie only makes a difference when CGO is involved, and for binaries that don't otherwise need CGO it only exists to tick a "make everything PIE" box and doesn't improve security. atl that's what the go authors have said.
2021-10-05 18:06:35     Seirdy  wondering if any apk devs can chime in
2021-10-05 20:30:05     psykose if it doesn't harm security but is sometimes used (cgo) then it should just always be there anyway
2021-10-05 20:30:13     psykose the pie flag, that is
2021-10-06 01:18:10     ncopa   Seirdy: what is the downside with static PIE? you mention that it means that binaries are linked to dynamic loader but that does not seem to be the case
2021-10-06 01:19:32     ncopa   ah.. you are right. the dynamic linker is actually needed
2021-10-06 01:20:27     ncopa   so the downside is that you cannot copy the binary to a place with different libc
2021-10-06 01:21:59     ncopa   not sure it is worth to separate buildmode=pie
2021-10-06 01:23:05     ncopa   i mean, i understand the benefit, but I'm not sure its worth the extra work, and risk to unintentionally disable PIE where it should be enabled
--
2021-10-06 07:09:28     Hello71 Seirdy: i disagree with your premise that it is a problem for distro packages to require distro files, and i assume fedora commenters will say the same. additionally, the claim that aslr has no benefits for go code is belied by the fact that go data races can still cause arbitrary memory corruption. https://research.swtch.com/gorace,
2021-10-06 07:09:30     Hello71 https://insanitybit.github.io/2016/12/28/golang-and-rustlang-memory-safety, https://github.com/netanel01/ctf-writeups/blob/master/googlectf/2019/pwn_gomium/README.md
2021-10-06 07:10:34     Hello71 for your private binaries, you can use -buildmode pie -ldflags "-linktype external -extldflags -static-pie", but this doesn't actually "reduce attack surface"
2021-10-06 07:12:14     Hello71 for proof that -buildmode=pie does do something: package main; import ( "fmt"; "reflect" ); func main() { fmt.Printf("%p", reflect.ValueOf(main).Pointer()) }
2021-10-06 07:13:30     Hello71 running this program without -buildmode=pie always produces %!p(uintptr=4716288). with -buildmode=pie, it produces a large number that varies on each invocation
--
2021-10-06 10:37:07     Seirdy  Hello71: that link is interesting, but does the situation change when using buildmode=pie? my understanding is that the Go runtime uses a fixed address even if you run buildmode=pie, and that the pie buildmode exists for compliance but doesn't actually make the runtime """really""" position-independent.
2021-10-06 10:37:46     Hello71 i posted three links and also a test. did you run the test
2021-10-06 10:40:14      *      Seirdy scrolls up
2021-10-06 10:40:23     Seirdy  i just responded to what was in my highmon
2021-10-06 10:42:21     Seirdy  ncopa: PIE introduces complexity (CGO) and increases binary size, the latter of which might be a bit more relevant to Alpine; while ASLR is a Good Thing, buildmode=pie doesn't really achieve nearly what -pie does in a C toolchain, so I wasn't convinced it was worth the cost
2021-10-06 10:42:27     Seirdy  Hello71: I'll try running it later today
2021-10-06 10:46:24     dalias  skarnet, any idea what we should do there? (also maybe move this to #musl)
2021-10-06 10:48:15     Seirdy  Hello71: that test is interesting; do you know if it's a result of recent changes introduced after the golang-nuts thread I linked?