From nobody Sat Jan 25 19:21:11 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YgPg85hm2z5lnDY for ; Sat, 25 Jan 2025 19:21:24 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YgPg823mLz3RKn for ; Sat, 25 Jan 2025 19:21:24 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-43625c4a50dso20430045e9.0 for ; Sat, 25 Jan 2025 11:21:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737832883; x=1738437683; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VclXzKBju5iabiBtttyZeeDfBXmN/CGWIY8MYZijmqg=; b=B7nJ6y3QF5JZu7n4D9LXJ12ItPt+S8M7F8n/MSvHIKhnRu13oK//TvtkkmqBXyBvSE oARJsGphnpksGH1DqTS7IVmeKiakuVLADSaX7hTZhmDd1zQs/bropa0/k8WIx5BLRbwL NOIHMQrLygbAUYJ/aer1v3lQ4hqoboiPNWEKqZ8nJn3XzoMb0fbhuvjEzqQAkTKJqq0Y X1OXIP3edg2u6u4p0y8WnTFMa4TYbOhIZod9d37vQ+0qcf8ybwnQnoWQDyakxs098VSz qX486bbGZ0EoewuH3wEocdtTdwHe6sJBiwgImTomofy7krljcT0jJDndTSNDAvY3ol/C 69vA== X-Forwarded-Encrypted: i=1; AJvYcCXBKXOJofQfbcXk4T7QKht+Aog3Q4Fd3i/2Q8mzC1kTDpCbXkCetJmPICZ5P+bGBNjCasPa2+Es1CIgE8uqpJZk2mpd@freebsd.org X-Gm-Message-State: AOJu0Yzh9XA/e5Y3le85whLa2ZEK9X3XLCGv7oTjk+9wSJXi0PGJWoi3 mCYpDUa0rHi+/euy5gZejqmq7SwkuCXQKmHAaSlQJvNGFk/SYEPL6HwR5U+YknE= X-Gm-Gg: ASbGnctoFITJGRf9qBSHMcXvV84LxMIa3iNRcwQi34JgLIoOcnEn+SO347Yee0R9jt1 BX2lHoDdiqG8VRpVZrEWZyBa/BNz8QwL86EgHeP/GisGYTQCWv2NgoNL+05jrGpZOiUOx8MLa6Z IenRoj9TPbsqEAg+RYdQmkb4aGO2nXIj2Dv6H5lrIgW6PucX5r4aCN2k0h/V54ce3uTzFMEETGv r9FQgo0gnEnvnqqUlBPfbioDxZc6MedvOMSNQoLtYG6jZkNqxfxx68N+9TEvtWfOQd/JmlzRD4z GYuA7Rj0sjFsvOb16gM= X-Google-Smtp-Source: AGHT+IFzhRqQQnxznawyLk7leh5fUEMixsDLRBoEbEFO06kBHUvT/u/1U0z+PiKJ+GqFZ7uj4JO55g== X-Received: by 2002:a7b:c00f:0:b0:434:f5c0:32b1 with SMTP id 5b1f17b1804b1-4389eecb1f5mr311059915e9.15.1737832882700; Sat, 25 Jan 2025 11:21:22 -0800 (PST) Received: from smtpclient.apple ([131.111.5.201]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438bd4b9984sm70125435e9.28.2025.01.25.11.21.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jan 2025 11:21:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: git: f934e629dc22 - main - Add stack clash protection to the WITH_SSP flag From: Jessica Clarke In-Reply-To: <9fec6bfae287dfc123a359c3e1164ae2@FreeBSD.org> Date: Sat, 25 Jan 2025 19:21:11 +0000 Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C70A3E0-CC6D-4B0B-96A8-70636F08AC6B@freebsd.org> References: <202501251308.50PD8Qsg042260@gitrepo.freebsd.org> <81A8E695-5034-4945-8D07-DF95E76904D0@freebsd.org> <9fec6bfae287dfc123a359c3e1164ae2@FreeBSD.org> To: Alexander Leidinger X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Queue-Id: 4YgPg823mLz3RKn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] On 25 Jan 2025, at 19:09, Alexander Leidinger = wrote: >=20 > Am 2025-01-25 19:32, schrieb Jessica Clarke: >> On 25 Jan 2025, at 13:08, Alexander Leidinger = wrote: >>> The branch main has been updated by netchild: >>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3Df934e629dc22b859efabd3cdebc23b63= b04fa2bb >>> commit f934e629dc22b859efabd3cdebc23b63b04fa2bb >>> Author: Alexander Leidinger >>> AuthorDate: 2025-01-25 12:43:39 +0000 >>> Commit: Alexander Leidinger >>> CommitDate: 2025-01-25 12:45:53 +0000 >>> Add stack clash protection to the WITH_SSP flag >>> Some background info availabe in: >>> = https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Harden= ing-Guide-for-C-and-C++.html >>> = https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gc= c-part-3 >>> https://blog.llvm.org/posts/2021-01-05-stack-clash-protection/ >>> Reviewed by: emaste >>> Differential Revision: https://reviews.freebsd.org/D48651 >> Uh, it does require architecture-specific compiler support, which = isn=E2=80=99t >> implemented for all architectures in LLVM at least. RISC-V has only >> recently (as in 1.5 months ago so not even released yet) gained >> support, for example. So this is just going to spew out >> -Wunused-command-line-argument warnings, and errors with -Werror, no? >=20 > The online docs for gcc = (https://gcc.gnu.org/onlinedocs/gcc//Instrumentation-Options.html) tell = this: > ---snip--- > Most targets do not fully support stack clash protection. However, on = those targets -fstack-clash-protection will protect dynamic stack = allocations. -fstack-clash-protection may also provide limited = protection for static stack allocations if the target supports = -fstack-check=3Dspecific. > ---snip--- >=20 > I read this as it should not spill such warnings. Additionally other = options there are listed as limited to some architectures, but this one = is not listed as such. >=20 > The online docs of clang = (https://clang.llvm.org/docs/ClangCommandLineReference.html) do not = limit this option for some architectures while for other options (e.g. = -fzero-call-used-regs) it tells about architecture limits. >=20 > In a discussion on -current in November there was the opinion it may = depend on run time support, as I've searched but I've read only that = this option depends on stack guard pages in the kernel. I have not found = info about any required run-time support in e.g. libc or such (like for = -fstack-protector(-strong)). >=20 > If those docs are missing listing limits for this option, we can off = course enable this with a little bit of code in bsd.compiler.mk only for = those architectures where we do not get such warnings. Clang=E2=80=99s docs are just deficient here. If you go and read the = actual code[1] you can see that architectures have to opt in to the flag even being checked. Even AArch64 didn=E2=80=99t support it until LLVM 18, if = you look at the history. It looks like with Clang we end up using -Qunused-arguments so the warning/error is suppressed. That at least means the build doesn=E2=80=99t= fail, which I suppose is good, but I=E2=80=99m not sure we should be = promising that WITH_SSP will protect against stack clash then having the compiler silently emit unprotected code (for which we=E2=80=99re to blame, by = telling it to ignore the fact it=E2=80=99s not supported). This at least needs to = be documented that the protection will only be provided if supported by the compiler. Jess [1] = https://github.com/llvm/llvm-project/blob/4bcd8184a093d2d9f0aad1053dbb1367= 891da6a5/clang/lib/Driver/ToolChains/Clang.cpp#L3790