From 4a01fea4a96374a1359d43a280a236a3ea042a1c Mon Sep 17 00:00:00 2001 From: Dirk Engling Date: Fri, 6 Nov 2026 19:09:43 +0100 Subject: Enable RELRO everywhere than macos --- DESIGN | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'DESIGN') diff --git a/DESIGN b/DESIGN index b6e2050..b25b37c 100644 --- a/DESIGN +++ b/DESIGN @@ -116,13 +116,20 @@ Build hardening the shipped binary ---------------------------------- The production and debug binaries carry -fstack-protector-strong, PIE and -_FORTIFY_SOURCE=2; a GNU-style linker also gets full RELRO. Measured cost on +_FORTIFY_SOURCE=2; every linker but Apple's also gets full RELRO (-z relro,-z now). Measured cost on the announce hot path is 300 to 305 nanoseconds, under two per cent, and the individual flags sit inside the run-to-run noise: add_peer has few stack buffers, most buffer sizes are known at compile time so FORTIFY emits no runtime check, and PIE on arm64 is almost free. On x86-64 PIE costs a little more. End to end it is invisible, since a UDP announce is mostly kernel time. +RELRO is gated on the operating system because Apple's linker rejects -z. The +branch runs in the shell through a != assignment, the one form both bmake and +GNU make 4 accept; $(shell) is GNU only and GNU make 3.81, which stock macOS +ships, has neither. On that old make the != line is inert and leaves RELRO +empty, which is the right answer for macOS anyway, so every platform resolves +correctly without a make conditional. + The flags are not in OT_CFLAGS, so the sanitizer test builds do not inherit them. AddressSanitizer checks harder than FORTIFY does, and the two clash on FreeBSD, where a FORTIFY plus ASan build aborted a multi hash scrape that the -- cgit v1.3