Thread: _FORTIFY_SOURCE by default?
_FORTIFY_SOURCE=2 appears to be the default for package building on many Linux distributions now, as part of harding or security options. But we often hear about problems related to this only when we hand the source over to the packagers. So I think we might as well add this to our standard compilation options, for example in src/include/port/linux.h. What do you think?
Peter Eisentraut <peter_e@gmx.net> writes:
> _FORTIFY_SOURCE=2 appears to be the default for package building on many
> Linux distributions now, as part of harding or security options. But we
> often hear about problems related to this only when we hand the source
> over to the packagers. So I think we might as well add this to our
> standard compilation options, for example in src/include/port/linux.h.
> What do you think?
Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
To the extent that this option finds anything useful (which in my
experience is a negligibly small percentage anyway), it's the
responsibility of the packagers (including me) to report it.
regards, tom lane
On 09/16/2012 12:41 AM, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> _FORTIFY_SOURCE=2 appears to be the default for package building on many >> Linux distributions now, as part of harding or security options. But we >> often hear about problems related to this only when we hand the source >> over to the packagers. So I think we might as well add this to our >> standard compilation options, for example in src/include/port/linux.h. >> What do you think? > Doesn't seem like a good idea to me to add platform-specific options > with unspecified effects to platform-independent upstream sources. > > To the extent that this option finds anything useful (which in my > experience is a negligibly small percentage anyway), it's the > responsibility of the packagers (including me) to report it. > > Might be worth having a buildfarm animal or two building with it, say by setting CFLAGS before configure? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/16/2012 12:41 AM, Tom Lane wrote:
>> Doesn't seem like a good idea to me to add platform-specific options
>> with unspecified effects to platform-independent upstream sources.
> Might be worth having a buildfarm animal or two building with it, say by
> setting CFLAGS before configure?
Possibly, but only if we actually pay attention to build warnings on
those animals.
regards, tom lane
On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > _FORTIFY_SOURCE=2 appears to be the default for package building on many > > Linux distributions now, as part of harding or security options. But we > > often hear about problems related to this only when we hand the source > > over to the packagers. So I think we might as well add this to our > > standard compilation options, for example in src/include/port/linux.h. > > What do you think? > > Doesn't seem like a good idea to me to add platform-specific options > with unspecified effects to platform-independent upstream sources. It's effectively a warning option, and we end up fixing all the warnings anyway, so I don't see the point of deferring that effort. We could rephrase this request as, how about adding this new warning option, it's occasionally useful -- which we frequently do. We add platform-specific warning and optimization options in many places, and I don't think this is much different.
On Sun, 2012-09-16 at 10:36 -0400, Andrew Dunstan wrote: > Might be worth having a buildfarm animal or two building with it, say by > setting CFLAGS before configure? I don't really see the value in that. Either this is part of our standard set of warnings and checks that we are interested in, and then everyone should see it, or we don't care about this, and then we should ignore the issue altogether. Creating different diagnostics sets for different people and different circumstances without clear purpose one way or the other just creates friction.
Peter Eisentraut <peter_e@gmx.net> writes:
> On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
>> Doesn't seem like a good idea to me to add platform-specific options
>> with unspecified effects to platform-independent upstream sources.
> It's effectively a warning option, and we end up fixing all the warnings
> anyway, so I don't see the point of deferring that effort. We could
> rephrase this request as, how about adding this new warning option, it's
> occasionally useful -- which we frequently do.
> We add platform-specific warning and optimization options in many
> places, and I don't think this is much different.
Maybe we're talking past each other. What I thought you meant was
adding this #define unconditionally, without any awareness of what it
might do on particular platforms. If you are thinking of adding it
only on platforms where it is considered standard, I can live with that.
Another point to consider here is that (at least on Red Hat) I believe
this enables address-space randomization; which is something I very much
do not want to happen in debug builds.
Bottom line is if you just want a new configure option for this, I don't
particularly object ... but on the other hand I also don't see the
usefulness. It's already possible for packagers who want the flag
to inject it, and for buildfarm owners who want to test the case to do
so.
regards, tom lane
On Sun, 2012-09-16 at 15:58 -0400, Tom Lane wrote: > Maybe we're talking past each other. What I thought you meant was > adding this #define unconditionally, without any awareness of what it > might do on particular platforms. If you are thinking of adding it > only on platforms where it is considered standard, I can live with > that. I had suggested to put it into src/include/port/linux.h > > Another point to consider here is that (at least on Red Hat) I believe > this enables address-space randomization; which is something I very > much do not want to happen in debug builds. I doubt that a preprocessor symbol has anything to do with address-space randomization. You are probably thinking of some other option that comes in with the hardening/security flags.
Peter Eisentraut <peter_e@gmx.net> writes:
> On Sun, 2012-09-16 at 15:58 -0400, Tom Lane wrote:
>> Maybe we're talking past each other. What I thought you meant was
>> adding this #define unconditionally, without any awareness of what it
>> might do on particular platforms. If you are thinking of adding it
>> only on platforms where it is considered standard, I can live with
>> that.
> I had suggested to put it into src/include/port/linux.h
OK, that's probably reasonable.
>> Another point to consider here is that (at least on Red Hat) I believe
>> this enables address-space randomization; which is something I very
>> much do not want to happen in debug builds.
> I doubt that a preprocessor symbol has anything to do with address-space
> randomization. You are probably thinking of some other option that
> comes in with the hardening/security flags.
[ pokes around... ] You're right, I was confusing this with
"_hardened_build".
regards, tom lane
On Mon, 2012-09-17 at 23:10 -0400, Tom Lane wrote: > > I had suggested to put it into src/include/port/linux.h > > OK, that's probably reasonable. It turns out that doesn't work because port.h is included after all the interesting libc header files (stdio.h etc.). I think the best place to put it is going to be src/template/linux. That would mirror the existing practice of putting it on the compiler command line.