Initial implementation of _FORTIFY_SOURCE

[Kyle Evans]

Hi,

As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.

This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.

Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Thanks,

Kyle Evans


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Cy Schubert]

In message <f8000e6b-226b-45f3-a751-***@FreeBSD.org>, Kyle Evans
write

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.
This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.
Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Should this trigger a __FreeBSD_version bump?
--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: https://FreeBSD.org
NTP: <***@nwtime.org> Web: https://nwtime.org

e^(i*pi)+1=0




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tomoaki AOKI]

On Mon, 13 May 2024 18:57:26 +0000

Post by Shawn Webb

Post by Cy Schubert
write

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.
This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.
Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Should this trigger a __FreeBSD_version bump?

I would encourage that so to help the ports tree determine
availability of the import.

If it can be enabled/disabled with sysctls/tunables on runtime/boottime,
bump should be preferred. Maybe this isn't yet the case here, IIUC.

But if it could be done only on build time with WITH_ or WITHOUT_ knob
ad not yet enabled by default for now, now ins't the time to bump.
Bump should be done when it becomes to be built by default.

Bump for non-default build time knob should force poudriere[-devel]
users massive unneeded rebuilds. So should be avoided, if it still
cannot switch on boot or runtime.

Post by Shawn Webb
Additionally, I've enabled _FORTIFY_SOURCE in HardenedBSD base[1] and
ports[2]. For base, it's only set (and to 2 by default) when MK_SSP is
set to yes. In ports, it's set by default except for ports that have
"kmod" in their USES.
Are there any plans to support _FORTIFY_SOURCE in the kernel?
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/927fd28755da27c5dd2b1b0d0396c93db585f933
https://git.hardenedbsd.org/hardenedbsd/ports/-/commit/3d7dcd284ce3083103edd6b28b3d232abbfeaa63
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal: [phone] / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[Alexander Leidinger]

Post by Kyle Evans

Post by Tomoaki AOKI
On Mon, 13 May 2024 18:57:26 +0000

Post by Shawn Webb

Post by Cy Schubert
write

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.
This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.
Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Should this trigger a __FreeBSD_version bump?

I would encourage that so to help the ports tree determine
availability of the import.

If it can be enabled/disabled with sysctls/tunables on
runtime/boottime,
bump should be preferred. Maybe this isn't yet the case here, IIUC.
But if it could be done only on build time with WITH_ or WITHOUT_ knob
ad not yet enabled by default for now, now ins't the time to bump.
Bump should be done when it becomes to be built by default.
Bump for non-default build time knob should force poudriere[-devel]
users massive unneeded rebuilds. So should be avoided, if it still
cannot switch on boot or runtime.

It's strictly build time, and I didn't really see the value in bumping
__FreeBSD_version for it. I don't see any reason to, e.g., turn it
into a per-port option that we may not want to have if the feature
isn't there, and the knob to build it in is a preprocessor define
that's harmless if the feature isn't actually available.

Ports: We have WITH_PIE, WITH_BIND_NOW and WITH_RELRO (e.g. for
make.conf) which enables those build time options globally. Ports then
can have e.g. PIE_UNSAFE=yes to opt-out of WITH_PIE builds. I think it
would be beneficial if we get something similar for FORTIFY. I already
use all of the afore mentioned options in my own builds (and have
provided NO_PIE hints where it fails), and I would surely give a similar
FORTIFY option a try.

On a somewhat related note, has someone already played with CFI
(https://clang.llvm.org/docs/ControlFlowIntegrity.html)?

Bye,
Alexander.

[Kyle Evans]

Post by Tomoaki AOKI
On Mon, 13 May 2024 18:57:26 +0000

Post by Shawn Webb

Post by Cy Schubert
write

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.
This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.
Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Should this trigger a __FreeBSD_version bump?

I would encourage that so to help the ports tree determine
availability of the import.

If it can be enabled/disabled with sysctls/tunables on runtime/boottime,
bump should be preferred. Maybe this isn't yet the case here, IIUC.
But if it could be done only on build time with WITH_ or WITHOUT_ knob
ad not yet enabled by default for now, now ins't the time to bump.
Bump should be done when it becomes to be built by default.
Bump for non-default build time knob should force poudriere[-devel]
users massive unneeded rebuilds. So should be avoided, if it still
cannot switch on boot or runtime.

It's strictly build time, and I didn't really see the value in bumping
__FreeBSD_version for it. I don't see any reason to, e.g., turn it into
a per-port option that we may not want to have if the feature isn't
there, and the knob to build it in is a preprocessor define that's
harmless if the feature isn't actually available.

Thanks,

Kyle Evans


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Shawn Webb]

Post by Kyle Evans

Post by Tomoaki AOKI
On Mon, 13 May 2024 18:57:26 +0000

Post by Shawn Webb

Post by Cy Schubert
In message
Evans
write

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for
_FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD.
FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided
checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.
This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.
Please test _FORTIFY_SOURCE out now by setting
FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when
WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Should this trigger a __FreeBSD_version bump?

I would encourage that so to help the ports tree determine
availability of the import.

If it can be enabled/disabled with sysctls/tunables on
runtime/boottime,
bump should be preferred. Maybe this isn't yet the case here, IIUC.
But if it could be done only on build time with WITH_ or WITHOUT_ knob
ad not yet enabled by default for now, now ins't the time to bump.
Bump should be done when it becomes to be built by default.
Bump for non-default build time knob should force poudriere[-devel]
users massive unneeded rebuilds. So should be avoided, if it still
cannot switch on boot or runtime.

It's strictly build time, and I didn't really see the value in bumping
__FreeBSD_version for it. I don't see any reason to, e.g., turn it into
a per-port option that we may not want to have if the feature isn't
there, and the knob to build it in is a preprocessor define that's
harmless if the feature isn't actually available.

Ports: We have WITH_PIE, WITH_BIND_NOW and WITH_RELRO (e.g. for make.conf)
which enables those build time options globally. Ports then can have e.g.
PIE_UNSAFE=yes to opt-out of WITH_PIE builds. I think it would be beneficial
if we get something similar for FORTIFY. I already use all of the afore
mentioned options in my own builds (and have provided NO_PIE hints where it
fails), and I would surely give a similar FORTIFY option a try.
On a somewhat related note, has someone already played with CFI
(https://clang.llvm.org/docs/ControlFlowIntegrity.html)?

HardenedBSD applies non-Cross-DSO CFI to (nearly) all applications in
base and has some integration in ports, with a few ports opting into
CFI. Feel free to reach out directly to me for specific questions so
that we don't get off-topic for this mailing list thread.

Thanks,

[Shawn Webb]

Post by Cy Schubert
write

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is an
improvement over classical SSP, doing compiler-aided checking of stack
object sizes to detect more fine-grained stack overflow without relying
on the randomized stack canary just past the stack frame.
This implementation is not yet complete, but we've done a review of
useful functions and syscalls to add checked variants of and intend to
complete the implementation over the next month or so.
Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in the
buildworld env -- I intend to flip the default to 2 when WITH_SSP is set
in the next month if nobody complains about serious breakage. I've
personally been rolling with FORTIFY_SOURCE=2 for the last three years
that this has been sitting in a local branch, so I don't really
anticipate any super-fundamental breakage.

Should this trigger a __FreeBSD_version bump?

I would encourage that so to help the ports tree determine
availability of the import.

Additionally, I've enabled _FORTIFY_SOURCE in HardenedBSD base[1] and
ports[2]. For base, it's only set (and to 2 by default) when MK_SSP is
set to yes. In ports, it's set by default except for ports that have
"kmod" in their USES.

Are there any plans to support _FORTIFY_SOURCE in the kernel?

[1]:
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/927fd28755da27c5dd2b1b0d0396c93db585f933
[2]:
https://git.hardenedbsd.org/hardenedbsd/ports/-/commit/3d7dcd284ce3083103edd6b28b3d232abbfeaa63

Thanks,

[Alexander Leidinger]

Post by Kyle Evans
Hi,
As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've imported
an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE is
an improvement over classical SSP, doing compiler-aided checking of
stack object sizes to detect more fine-grained stack overflow without
relying on the randomized stack canary just past the stack frame.

This breaks some port builds.

Example libfido2 (which is a dependency in the build of e.g. mysql):
---snip---
[ 0% 4/1032] /usr/local/libexec/ccache/cc -DHAVE_ARC4RANDOM_BUF
-DHAVE_ASPRINTF -DHAVE_CLOCK_GETTIME -DHAVE_DEV_URANDOM -DHAVE_ENDIAN_H
-DHAVE_ERR_H -DHAVE_EXPLICIT_BZERO -DHAVE_GETLINE -DHAVE_GETOPT
-DHAVE_GETPAGESIZE -DHAVE_GETRANDOM -DHAVE_OPENSSLV_H
-DHAVE_READPASSPHRASE -DHAVE_SIGNAL_H -DHAVE_STRLCAT -DHAVE_STRLCPY
-DHAVE_STRSEP -DHAVE_SYSCONF -DHAVE_SYS_RANDOM_H -DHAVE_TIMESPECSUB
-DHAVE_TIMINGSAFE_BCMP -DHAVE_UNISTD_H -DOPENSSL_API_COMPAT=0x10100000L
-DTLS=__thread -D_FIDO_INTERNAL -D_FIDO_MAJOR=1 -D_FIDO_MINOR=14
-D_FIDO_PATCH=0
-I/wrkdirs/usr/ports/security/libfido2/work/libfido2-1.14.0/src
-I/usr/local/include -D_POSIX_C_SOURCE=200809L -D_BSD_SOURCE
-D__BSD_VISIBLE=1 -std=c99 -O2 -pipe -O2 -pipe -mtune=native -fvectorize
-O2 -pipe -mtune=native -fvectorize -march=native
-DOPENSSL_API_COMPAT=0x10100000L -fstack-protector-strong
-fno-strict-aliasing -O2 -pipe -O2 -pipe -mtune=native -fvectorize -O2
-pipe -mtune=native -fvectorize -march=native
-DOPENSSL_API_COMPAT=0x10100000L -fstack-protector-strong
-fno-strict-aliasing -DNDEBUG -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wextra
-Werror -Wshadow -Wcast-qual -Wwrite-strings -Wmissing-prototypes
-Wbad-function-cast -Wimplicit-fallthrough -pedantic -pedantic-errors
-Wshorten-64-to-32 -fstack-protector-all -Wconversion -Wsign-conversion
-Wframe-larger-than=2047 -MD -MT src/CMakeFiles/fido2.dir/aes256.c.o -MF
src/CMakeFiles/fido2.dir/aes256.c.o.d -o
src/CMakeFiles/fido2.dir/aes256.c.o -c
/wrkdirs/usr/ports/security/libfido2/work/libfido2-1.14.0/src/aes256.c
FAILED: src/CMakeFiles/fido2.dir/aes256.c.o
/usr/local/libexec/ccache/cc -DHAVE_ARC4RANDOM_BUF -DHAVE_ASPRINTF
-DHAVE_CLOCK_GETTIME -DHAVE_DEV_URANDOM -DHAVE_ENDIAN_H -DHAVE_ERR_H
-DHAVE_EXPLICIT_BZERO -DHAVE_GETLINE -DHAVE_GETOPT -DHAVE_GETPAGESIZE
-DHAVE_GETRANDOM -DHAVE_OPENSSLV_H -DHAVE_READPASSPHRASE -DHAVE_SIGNAL_H
-DHAVE_STRLCAT -DHAVE_STRLCPY -DHAVE_STRSEP -DHAVE_SYSCONF
-DHAVE_SYS_RANDOM_H -DHAVE_TIMESPECSUB -DHAVE_TIMINGSAFE_BCMP
-DHAVE_UNISTD_H -DOPENSSL_API_COMPAT=0x10100000L -DTLS=__thread
-D_FIDO_INTERNAL -D_FIDO_MAJOR=1 -D_FIDO_MINOR=14 -D_FIDO_PATCH=0
-I/wrkdirs/usr/ports/security/libfido2/work/libfido2-1.14.0/src
-I/usr/local/include -D_POSIX_C_SOURCE=200809L -D_BSD_SOURCE
-D__BSD_VISIBLE=1 -std=c99 -O2 -pipe -O2 -pipe -mtune=native -fvectorize
-O2 -pipe -mtune=native -fvectorize -march=native
-DOPENSSL_API_COMPAT=0x10100000L -fstack-protector-strong
-fno-strict-aliasing -O2 -pipe -O2 -pipe -mtune=native -fvectorize -O2
-pipe -mtune=native -fvectorize -march=native
-DOPENSSL_API_COMPAT=0x10100000L -fstack-protector-strong
-fno-strict-aliasing -DNDEBUG -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wextra
-Werror -Wshadow -Wcast-qual -Wwrite-strings -Wmissing-prototypes
-Wbad-function-cast -Wimplicit-fallthrough -pedantic -pedantic-errors
-Wshorten-64-to-32 -fstack-protector-all -Wconversion -Wsign-conversion
-Wframe-larger-than=2047 -MD -MT src/CMakeFiles/fido2.dir/aes256.c.o -MF
src/CMakeFiles/fido2.dir/aes256.c.o.d -o
src/CMakeFiles/fido2.dir/aes256.c.o -c
/wrkdirs/usr/ports/security/libfido2/work/libfido2-1.14.0/src/aes256.c
/wrkdirs/usr/ports/security/libfido2/work/libfido2-1.14.0/src/aes256.c:18:2:
error: use of GNU statement expression extension from macro expansion
[-Werror,-Wgnu-statement-expression-from-macro-expansion]
18 | memset(out, 0, sizeof(*out));
| ^
/usr/include/ssp/string.h:120:5: note: expanded from macro 'memset'
120 | __ssp_bos_check3_typed(memset, void *, dst, int, val, len)
| ^
/usr/include/ssp/string.h:65:5: note: expanded from macro
'__ssp_bos_check3_typed'
65 | __ssp_bos_check3_typed_var(fun, dsttype, __ssp_var(dstv),
dst, \
| ^
/usr/include/ssp/string.h:54:24: note: expanded from macro
'__ssp_bos_check3_typed_var'
54 | src, lenvar, len) ({ \
| ^
/wrkdirs/usr/ports/security/libfido2/work/libfido2-1.14.0/src/aes256.c:60:2:
error: use of GNU statement expression extension from macro expansion
[-Werror,-Wgnu-statement-expression-from-macro-expansion]
60 | memset(&iv, 0, sizeof(iv));
| ^
/usr/include/ssp/string.h:120:5: note: expanded from macro 'memset'
120 | __ssp_bos_check3_typed(memset, void *, dst, int, val, len)
| ^
/usr/include/ssp/string.h:65:5: note: expanded from macro
'__ssp_bos_check3_typed'
65 | __ssp_bos_check3_typed_var(fun, dsttype, __ssp_var(dstv),
dst, \
| ^
/usr/include/ssp/string.h:54:24: note: expanded from macro
'__ssp_bos_check3_typed_var'
54 | src, lenvar, len) ({ \
| ^
---snip---

I also have a failed archivers/libdeflate, devel/highway, www/node20,
and lang/rust, but those complain about something which could also be
attributed to some kind of interaction between my use of -fvectorize and
the new fortify stuff. Example with libdeflate (the libdeflate update in
ports is from March, and I had it compiled with -fvectorize successfully
before the fortify stuff came in):
---snip---
In file included from
/wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_impl.h:93:
/wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:197:21:
error: always_inline function '_mm512_set1_epi8' requires target feature
'evex512', but would be inlined into function
'adler32_x86_avx512_vl512_vnni' that is compiled without support for
'evex512'
197 | const vec_t ones = VSET1_8(1);
| ^
---snip---
Note, my CPUs don't support evex512 or avx512 at all, the compile flags
haven't changed, this version of the port is installed in multiple jails
(since March 28), so there is a change in behavior since then. It may or
may not be due to the fortify stuff.

I will test without -fvectorize later, poudriere is still building
ports, and I want to see if some other ports fail. Those 5 failed port
builds result in 160 skipped ports already (out of the >600 which this
run wants to build).

Maybe you want to backout and request an exp-build to not get swamped
with failure reports from various people...

Bye,
Alexander.

[Alexander Leidinger]

I've confirmed that this patch fixes libfido2, will commit shortly.

I can confirm too.

If I want to test this on more ports, I have to add -D_FORTIFY_SOURCE=2
to the CFLAGS / CSSFLAGS? Or rather do this:
---snip---
diff --git a/Mk/Features/ssp.mk b/Mk/Features/ssp.mk
index 4213e6d668a..545e74bfa05 100644
--- a/Mk/Features/ssp.mk
+++ b/Mk/Features/ssp.mk
@@ -7,8 +7,10 @@ SSP_Include_MAINTAINER= ***@FreeBSD.org
. if !defined(SSP_UNSAFE) && \
(! ${ARCH:Mmips*})
# Overridable as a user may want to use -fstack-protector-all
-SSP_CFLAGS?= -fstack-protector-strong
+SSP_CFLAGS?= -fstack-protector-strong -D_FORTIFY_SOURCE=2
+SSP_LDFLAGS?= -fstack-protector-strong
CFLAGS+= ${SSP_CFLAGS}
-LDFLAGS+= ${SSP_CFLAGS}
+CXXFLAGS+= ${SSP_CFLAGS}
+LDFLAGS+= ${SSP_LDFLAGS}
. endif
.endif
---snip---

Bye,
Alexander.