On Thu, Dec 22, 2016 at 2:09 PM, Aaron Wood <[email protected]> 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]. > 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.
