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

From: Hans Buschmann <buschmann(at)nidsa(dot)net>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full
Date: 2026-07-07 09:59:35
Message-ID: 01e60576b689490a9388b3d840f23cd8@nidsa.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ewan Young 2026-07-07 10:08:42 Re: plpython: NULL pointer dereference on broken sequence objects
Previous Message Peter Eisentraut 2026-07-07 09:59:29 Re: truncating casts of pgoff_t