Interesting, thanks for the info Ian. Other than the OS and distro requirements, is there any real benefit from generating PIE binaries with Go? There must be some vector that it protects again, even though most things are already bounds-checked. The only situation I can think of is if you're calling C from Go. There must be other rare, obscure ways to exploit overflows in code generated from Go, no?
On Thursday, December 22, 2016 at 5:31:14 PM UTC-5, Ian Lance Taylor wrote: > > On Thu, Dec 22, 2016 at 2:09 PM, Aaron Wood <[email protected] > <javascript:>> wrote: > > > > This is a rather old comment of yours but I was curious about a few > things > > you said. I agree that Go does take care of a lot of these problems (and > > most other high-level languages try to too) so I'm curious as to why Go > has > > exposed a build option for generating position independent executables > > (buildmode=pie). This is something I use and think it is a great feature > to > > have exposed but if the goal was to address most of this stuff at the > > language level then what was the reason for exposing this to users of > Go? I > > don't think most other high-level languages let you control this > > setting...although I guess most of them don't really compile down to a > > native binary in the end. > > Go exposes supports generating PIE because an increasing number of > operating system distros require it, or at least use it by default > (for example, I believe that non-Java Android apps must be PIE). The > distros do this because the distro maintainers feel that it addresses > problems with programs written in C/C++. Since from the operating > system perspective Go programs are indistinguishable from C/C++ > programs, Go needs to be able to generate PIE just as C/C++ do. > > As you say, discussing PIE is only relevant for a language that > compiles into a native binary. > > Ian > > > > On Monday, April 30, 2012 at 10:21:06 PM UTC-4, Russ Cox wrote: > >> > >> On Mon, Apr 30, 2012 at 21:51, David Leimbach <[email protected]> > wrote: > >> > I was just playing with pointers yesterday, trying to understand a > >> > memory > >> > issue I thought I was having (me not remembering the memory model > >> > mostly). > >> > > >> > I came to the conclusion that pointers were showing up at very much > the > >> > same > >> > memory addresses each time, and that perhaps randomizing this would > be a > >> > good idea. > >> > >> Address space randomization is an OS-level workaround for a > >> language-level problem, namely that simple C programs tend to be full > >> of exploitable buffer overflows. Go fixes this at the language level, > >> with bounds-checked arrays and slices and no dangling pointers, which > >> makes the OS-level workaround much less important. In return, we > >> receive the incredible debuggability of deterministic address space > >> layout. I would not give that up lightly. > >> > >> Russ > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
