Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wh2ai-0000tP-0T for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jul 2026 09:59:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wh2ag-000Du2-0z for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jul 2026 09:59:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wh2af-000Dsb-2q for pgsql-hackers@lists.postgresql.org; Tue, 07 Jul 2026 09:59:46 +0000 Received: from ma04-relay.lansolnet.com ([176.95.46.38]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wh2ad-000000000Lb-2Bwa for pgsql-hackers@postgresql.org; Tue, 07 Jul 2026 09:59:45 +0000 ARC-Authentication-Results: i=1; ma04.lansolnet.com 1; spf=pass reason=mailfrom (ip=194.126.198.214, headerfrom=nidsa.net) smtp.mailfrom=nidsa.net smtp.helo=mail.cloud4partner.com; ARC-Message-Signature: a=rsa-sha256; bh=+4cEVHC4H52YnsB/rJ85VZraQOtKndo6e/DHRA/H0dc=; c=relaxed/relaxed; d=hornetsecurity.com; h=from:to:date:subject:mime-version:; i=1; s=hse1; t=1783418378; b=jvn/Dg0b9SwGEpcCBkSUntNw5rXyH5tiRl3GZgWh/0k9uSIYxSrPOpM0LSBBJUXqeHOhKBqv i/Jhn6tqvvQfAjPnAlk6wGNXZNt2s0l92VBEyCg15iYO7wPp8JyOHTYVMpEkQRr27ghU0+brRNi PaDw39nWYMQLVJVE/Id3aB0GGqlu75i4Znz7GhfTyKJzsfvzo23rcpGqlnbyrObKsCgInAUbBzS UlU8O5RmeVIimIhy76frySNbvbNZCWPxeC/xFJy+yoCJtkteFJEVca1GDS3uvbd9qJrfbuRZsKL DPStMmBp2tJ3+fdYdNJBs7mWvJtAmdo6uGZSCbR24eB0A== ARC-Seal: a=rsa-sha256; cv=none; d=hornetsecurity.com; i=1; s=hse1; t=1783418378; b=BzBZ62ALDh5vgRIPhRKawWdKqk6Bh2qW4jq4aKHbXNtg2WKPCsyvwTgWkUV4zHu6z8U2fAut BtxYX/Tat0Ease/bw9v8pbNIrZH2qOdH6QRyB9BF+b986tBi5JmdX605o6BNEU3uWK9xifxyaQZ Zi2eYk1FFhlSAf/xCqC0sW1vgNct5kQi7i5ZAnchJklDKlvwznJyivyCka81iIOtCrfgguApW1g aaJ4zBwfR/SuPF3BDOHekXE32QDQXSkvj4E+jFK4yDPTJY+cR8O+jNBbHCyZe0g1TdF1JnEI0tm wB0hQQmpvZaZq/xKNnowTBEAiEy56fLTeYLFmuu2nqFOw== Received: from unknown ([194.126.198.214]) by ma04; Tue, 07 Jul 2026 11:59:38 +0200 Received: from MBX200E.cloud4partner.com (192.168.8.234) by MBX200D.cloud4partner.com (192.168.8.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2507.44; Tue, 7 Jul 2026 11:59:35 +0200 Received: from MBX200E.cloud4partner.com ([fe80::e4a1:818c:c1f9:8e28]) by MBX200E.cloud4partner.com ([fe80::e4a1:818c:c1f9:8e28%15]) with mapi id 15.01.2507.044; Tue, 7 Jul 2026 11:59:35 +0200 From: Hans Buschmann To: "pgsql-hackers@postgresql.org" Subject: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Thread-Topic: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full Thread-Index: AQHdDfHp3FHAPcaRdEG7InD/TwDpBQ== Date: Tue, 7 Jul 2026 09:59:35 +0000 Message-ID: <01e60576b689490a9388b3d840f23cd8@nidsa.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.8.240] Content-Type: multipart/alternative; boundary="_000_01e60576b689490a9388b3d840f23cd8nidsanet_" MIME-Version: 1.0 X-cloud-security-sender: buschmann@nidsa.net X-cloud-security-recipient: pgsql-hackers@postgresql.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on ma04 with 7DBC2B80145 X-cloud-security-connect: unknown[194.126.198.214], TLS=1, IP=194.126.198.214 X-cloud-security: scantime:.5091 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_01e60576b689490a9388b3d840f23cd8nidsanet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some days ago I stumbled over the following Phoronix article with a proposa= l for Fedora 45: Fedora 45 Considering x86_64 Shadow Stack Usage By Default 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 pg1= 9,, 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 Indir= ect 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) th= ese 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 opti= ons disables the checks for all processes loading it. It may sometimes be necessary that a quick fix of an apparent bug encourage= s the user to recomple the specific component of postgres. The different co= mpile 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 d= istributed 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 (autoconfigu= re and meson) Please consider different operating systems (red hat, debian etc), all supp= orted 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 PGD= G. In the course of strict reproducability by the end user (some debian eff= orts) these options should be documented with every release and activated a= ccordingly in all supported buid systems. Thank you for investigating! Hans Buschmann --_000_01e60576b689490a9388b3d840f23cd8nidsanet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Some days ago I stumbled over the following Phoronix article with a prop= osal for Fedora 45:


Fedora 45 Considering x86_64 Shadow Stack Usage By Default


https://www.phoronix.com/news/Fedora-45-Consider-Sh= adow-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 (SHS= TK) 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 differen= t blocksize) these options are not set by default (built with meson on curr= ent fedora 44).


To my little understanding of this topic a library missing t= he compile options disables the checks for all processes loading it.=


It may sometimes be necessary that a quick fix of an apparen= t bug encourages the user to recomple the specific component of postgres. T= he different compile options result in  that the operating s= ystem provided protection can not be guaranteed.


I have discovered this case on x86_64 pg18 on linux built wi= th meson but I don't know if other architectures have similar mitigati= ons 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 t= hat 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 c= ompilers, different built systems etc.



This is also important for a reproducability of the build pr= ocess.


It is not clearly visible, with which options the releases a= re 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


--_000_01e60576b689490a9388b3d840f23cd8nidsanet_--