Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
Some days ago I stumbled over the following Phoronix article with a proposal for Fedora 45:
Fedora 45 Considering x86_64 Shadow Stack Usage By Default<https://www.phoronix.com/news/Fedora-45-Consider-Shadow-Stack>
https://www.phoronix.com/news/Fedora-45-Consider-Shadow-Stack
The background is being discussed in Fedora Wiki:
https://fedoraproject.org/wiki/Changes/ShadowStack
(Fedora 45 is the upcomning release scheduled for fall 2026 short after pg19,, probably carrying GCC 17.x and Postgres 19 with it.)
I exemplary checked both the Fedora provided packages and the PGDG provided packages of pg18 that they are build with Schadow Stack (SHSTK) and Indirect Branch Tracking (IBT) activated which is true.
It easily can be checked (for any image,library,object) with
readelf -n postgres | grep 'IBT\|SHSTK'
BUT:
For a self-compiled version of postgres (e.g. for a different blocksize) these options are not set by default (built with meson on current fedora 44).
To my little understanding of this topic a library missing the compile options disables the checks for all processes loading it.
It may sometimes be necessary that a quick fix of an apparent bug encourages the user to recomple the specific component of postgres. The different compile options result in that the operating system provided protection can not be guaranteed.
I have discovered this case on x86_64 pg18 on linux built with meson but I don't know if other architectures have similar mitigations enabled in the distributed binaries.
As I am not an experienced C-Programmer, there may be other compile options for other vulnerabilities.
I propose to activate all compiler options as default that are used in the binary releases of postgres, preferrably in both built systems (autoconfigure and meson)
Please consider different operating systems (red hat, debian etc), all supported pg versions, different architectures, different compilers, different built systems etc.
This is also important for a reproducability of the build process.
It is not clearly visible, with which options the releases are build by PGDG. In the course of strict reproducability by the end user (some debian efforts) these options should be documented with every release and activated accordingly in all supported buid systems.
Thank you for investigating!
Hans Buschmann
On 07.07.26 11:59, Hans Buschmann wrote:
Some days ago I stumbled over the following Phoronix article with a
proposal for Fedora 45:Fedora 45 Considering x86_64 Shadow Stack Usage By Default <https://
www.phoronix.com/news/Fedora-45-Consider-Shadow-Stack>
I exemplary checked both the Fedora provided packages and the PGDG
provided packages of pg18 that they are build with Schadow Stack
(SHSTK) and Indirect Branch Tracking (IBT) activated which is true.
It may sometimes be necessary that a quick fix of an apparent bug
encourages the user to recomple the specific component of postgres. The
different compile options result in that the operating system provided
protection can not be guaranteed.I have discovered this case on x86_64 pg18 on linux built with meson but
I don't know if other architectures have similar mitigations enabled in
the distributed binaries.As I am not an experienced C-Programmer, there may be other compile
options for other vulnerabilities.I propose to activate all compiler options as default that are used in
the binary releases of postgres, preferrably in both built systems
(autoconfigure and meson)Please consider different operating systems (red hat, debian etc), all
supported pg versions, different architectures, different compilers,
different built systems etc.
I don't think this would be a good direction. Distributions are in many
cases better placed to decide when and how to activate certain
protections. The case you point out here is a good example. The
-fcf-protection option was already activated in Fedora 28, but it is
only now that they are considering switching over the base layers of the
OS to activate this facility. It would be unreasonable to expect
PostgreSQL and any other open-source project to track this and sync up
with this. Consider this to see the amount of information that would
need to be tracked and implemented:
https://github.com/jvoisin/compiler-flags-distro
Hello Peter
Thanks for your quick response.
I totally agree that it is impossible to always follow all distributions with their specific compiler flags.
But my intention was a bit different: asking for internal consistency.
For distributions the PGDG publishes binaries for (see download page) a certain selection of compiler flags are choosen.
My intention is to set these flags as defaults for self-compiling on these platforms.
Most of the flags are compiler-driven, eventually changing with a new version.
I think it is important that these compiler options are DOCUMENTED (in the binary distributions) so that they can be set or verified when self-compiling.
I think the normal user cannot handle all these compiler options, it wants to use the tested and provided standard managed by the developers.
It is clear that the global benefits of some mitigations may arrive only much later (fedora 28 ->45).
I think in the near future (APX and AVX10.2) there will be new architectural opportunities which really could target performance on newer architectures. This will require a more thoughtfull choice of compiler options..
Hans Buschmann
On Wed, 8 Jul 2026 at 12:01, Hans Buschmann <buschmann@nidsa.net> wrote:
Most of the flags are compiler-driven, eventually changing with a new version.
I think it is important that these compiler options are DOCUMENTED (in the binary distributions) so that they can be set or verified when self-compiling.
You should be able to grab the compiler and compiler options used to
compile a binary distribution of PostgreSQL from the included
pg_config utility (or pg_config catalog view). Is there information
missing in there that you expected to be available?
I think the normal user cannot handle all these compiler options, it wants to use the tested and provided standard managed by the developers.
If the normal user cannot handle compiler options, then should they
really be self-compiling PostgreSQL with custom compiler options, for
a platform that already has pre-compiled binary distributions?
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
Hello Matthias,
Thank you for pointing me to the pg_config options. I didn't know and will take a look.
If the normal user cannot handle compiler options, then should they
really be self-compiling PostgreSQL with custom compiler options, for
a platform that already has pre-compiled binary distributions?
As already mentioned in my original post, there are some cases a "normal" user (in my terminology it is a db responsible not experienced with C programming practice) may use a manual recompile:
- blocksize change
- emergency patch: see current planet postgres:
- test on beta versions of the OS
- etc...
The user should be able to recompile the package (which is really very easy with meson after some setup of developer packages) without deeper knowledge of C programming with the original configuration of the distribution.
In production I use the binary distribution from PGDG and additionally compile the latest/beta versions for a compatibility check.
Best regards
Hans Buschmann
Hi Hans,
On Wed, 8 Jul 2026 at 13:24, Hans Buschmann <buschmann@nidsa.net> wrote:
Thank you for pointing me to the pg_config options. I didn't know and will take a look.
No problem!
If the normal user cannot handle compiler options, then should they
really be self-compiling PostgreSQL with custom compiler options, for
a platform that already has pre-compiled binary distributions?As already mentioned in my original post, there are some cases a "normal" user (in my terminology it is a db responsible not experienced with C programming practice) may use a manual recompile:
The user should be able to recompile the package (which is really very easy with meson after some setup of developer packages) without deeper knowledge of C programming with the original configuration of the distribution.
I agree, and generally, they are able to do that when they have the
original configuration of the distribution.
However, what you're asking here is that we, in the postgresql.git
repository, supply "the original configuration of the distribution".
That's not part of the scope of the postgresql.git repository.
Packagers are downstream consumers of our repository, and their
specific configurations are therefore not part of the main PG git
repository.
If you have problems with PGDG's binary distributions, or otherwise
questions (e.g. how to build your own binaries in a way that's
compatible with distributed versions), there are various channels you
can use to contact the packagers. For example, the apt repo's
maintainers can be contacted with the details found at
https://apt.postgresql.org#Contact
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)