public inbox for [email protected]
help / color / mirror / Atom feedIncreased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
6+ messages / 3 participants
[nested] [flat]
* Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
@ 2026-07-07 09:59 Hans Buschmann <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Hans Buschmann @ 2026-07-07 09:59 UTC (permalink / raw)
To: pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
@ 2026-07-07 12:25 Peter Eisentraut <[email protected]>
parent: Hans Buschmann <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Peter Eisentraut @ 2026-07-07 12:25 UTC (permalink / raw)
To: Hans Buschmann <[email protected]>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* AW: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
@ 2026-07-08 10:01 Hans Buschmann <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Hans Buschmann @ 2026-07-08 10:01 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
@ 2026-07-08 10:57 Matthias van de Meent <[email protected]>
parent: Hans Buschmann <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Matthias van de Meent @ 2026-07-08 10:57 UTC (permalink / raw)
To: Hans Buschmann <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
On Wed, 8 Jul 2026 at 12:01, Hans Buschmann <[email protected]> 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)
^ permalink raw reply [nested|flat] 6+ messages in thread
* AW: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
@ 2026-07-08 11:24 Hans Buschmann <[email protected]>
parent: Matthias van de Meent <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Hans Buschmann @ 2026-07-08 11:24 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
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...
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
@ 2026-07-08 15:49 Matthias van de Meent <[email protected]>
parent: Hans Buschmann <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Matthias van de Meent @ 2026-07-08 15:49 UTC (permalink / raw)
To: Hans Buschmann <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
Hi Hans,
On Wed, 8 Jul 2026 at 13:24, Hans Buschmann <[email protected]> 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)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-07-08 15:49 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-07 09:59 Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Hans Buschmann <[email protected]>
2026-07-07 12:25 ` Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Peter Eisentraut <[email protected]>
2026-07-08 10:01 ` AW: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Hans Buschmann <[email protected]>
2026-07-08 10:57 ` Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Matthias van de Meent <[email protected]>
2026-07-08 11:24 ` AW: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Hans Buschmann <[email protected]>
2026-07-08 15:49 ` Re: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Matthias van de Meent <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox