Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Jan 2025 19:21:11 +0000
From:      Jessica Clarke <jrtc27@freebsd.org>
To:        Alexander Leidinger <netchild@FreeBSD.org>
Cc:        src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject:   Re: git: f934e629dc22 - main - Add stack clash protection to the WITH_SSP flag
Message-ID:  <6C70A3E0-CC6D-4B0B-96A8-70636F08AC6B@freebsd.org>
In-Reply-To: <9fec6bfae287dfc123a359c3e1164ae2@FreeBSD.org>
References:  <202501251308.50PD8Qsg042260@gitrepo.freebsd.org> <81A8E695-5034-4945-8D07-DF95E76904D0@freebsd.org> <9fec6bfae287dfc123a359c3e1164ae2@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25 Jan 2025, at 19:09, Alexander Leidinger <netchild@FreeBSD.org> =
wrote:
>=20
> Am 2025-01-25 19:32, schrieb Jessica Clarke:
>> On 25 Jan 2025, at 13:08, Alexander Leidinger <netchild@FreeBSD.org> =
wrote:
>>> The branch main has been updated by netchild:
>>> URL: =
https://cgit.FreeBSD.org/src/commit/?id=3Df934e629dc22b859efabd3cdebc23b63=
b04fa2bb
>>> commit f934e629dc22b859efabd3cdebc23b63b04fa2bb
>>> Author:     Alexander Leidinger <netchild@FreeBSD.org>
>>> AuthorDate: 2025-01-25 12:43:39 +0000
>>> Commit:     Alexander Leidinger <netchild@FreeBSD.org>
>>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C70A3E0-CC6D-4B0B-96A8-70636F08AC6B>