From nobody Sat Jan 25 19:21:11 2025 X-Original-To: dev-commits-src-main@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 4YgPg858JNz5lnN3 for ; Sat, 25 Jan 2025 19:21:24 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 4YgPg82Lzqz3R6T 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-f43.google.com with SMTP id 5b1f17b1804b1-4361e89b6daso20265835e9.3 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=nsEP0Pt0wBgg5180yfE192pkd7kCHPVuqK1KHOxO/r/jSiuPN0bjMoSijiqp0xK6DL Czb1QGEGDmU5RsCx7epec4lAxJS4ZvgEAOMkiU3qiycNdyU3n85nLASVHA7eOUlSMeRh 0dtd19Hv0GG5BBac+bt5uhmEEo/KczndadPpNIEzfLDxP8IWxV73rBUw7dBYrSc6bUCe lBBjhH4kIB09W3VZO5C3OCYn4hVUnMuyaIX6VW4zrUfordV6KefaTEnOmOTnkJZfOvsA JPmDoYVX7S3yAADSDVDs0OFcdMcZyNgr14aCw064qmP3gDhfKZ/uSrq0tsz2F+oocCTM 25pw== X-Forwarded-Encrypted: i=1; AJvYcCWSSNJqT2izhGwLUUNzrCk6T3/316Os0uooKn/Gc3AvlxpPVEDxWPUT39nK/648s6leCeoiHP8nL15I84DXNgrfBMzshg==@freebsd.org X-Gm-Message-State: AOJu0YyCHLu9M0hvVARwpmLaP4QF3LWAqUMD3LKA5JmK3Nq9RQBYn5Nf PHRf7emupf0IpRVswpXOZMoOvFdzYRJhbRLnoRqRI429AMeGbXYUn4W9h8caHm6OTdjjSTvAlxK a X-Gm-Gg: ASbGnctCJM2efHu4jYOXLhwIT1gusyRkOlCp8WWtHK/rOkZg/oilGzp5OqmOOX7h8zE rFsLdR6xG2ngcTxpWurD73ahH4B5QrVEr/jKDqxPw50/PYJsUdmEafVBKh5MLWpj/KLQbiHg6Uv zCdUD76gXCiI9X68CAKXyqFq7ZWQqm9tH1QPf48T5LJng61llEsUNwHtDp7eZLfxDE43ST3oMyG 8ZiMrQ0ySt+0uyoIWm6Mlf8M6VQSA6PVfV9hO9dH1n1Gv+2jzVu36iS6P5H8FsKf3ex32a75Ofp i7R1hU6MCC8mfM/FKCk= 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 the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@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: 4YgPg82Lzqz3R6T 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