Thread

1. Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full

   Hans Buschmann <buschmann@nidsa.net> — 2026-07-07T09:59:35Z

   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
   
   

2. Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full

   Peter Eisentraut <peter@eisentraut.org> — 2026-07-07T12:25:49Z

   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
   
   
   
   
   

3. AW: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full

   Hans Buschmann <buschmann@nidsa.net> — 2026-07-08T10:01:32Z

   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
   
   

4. Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full

   Matthias van de Meent <boekewurm+postgres@gmail.com> — 2026-07-08T10:57:00Z

   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)
   
   
   
   

5. AW: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full

   Hans Buschmann <buschmann@nidsa.net> — 2026-07-08T11:24:55Z

   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...
   
   https://www.credativ.de/blog/postgresql/replikations-deadlock-fehler-in-aktuellen-postgres-versionen-14-16/
   
   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
   
   

6. Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full

   Matthias van de Meent <boekewurm+postgres@gmail.com> — 2026-07-08T15:49:16Z

   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)