Yes, it appears we can handle uclibc the same way
Uclibc-ng supports SSP in the library itself, so use of GCC_LIBSSP can
eliminated. I'll do some testing ...
config UCLIBC_HAS_SSP
bool "Support for GCC stack smashing protector"
depends on !HAVE_NO_SSP
help
Add code to support GCC's -fstack-protector[-all] option to uClibc.
This requires GCC 4.1 or newer. GCC does not have to provide libssp,
the needed functions are added to ldso/libc instead.
GCC's stack protector is a reimplementation of IBM's propolice.
See http://www.trl.ibm.com/projects/security/ssp/ and
http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt
for details.
Note that NOEXECSTACK on a kernel with address space randomization
is generally sufficient to prevent most buffer overflow exploits
without increasing code size. This option essentially adds debugging
code to catch them.
> -----Original Message-----
> From: Hauke Mehrtens [mailto:ha...@hauke-m.de]
> Sent: 24 May 2020 13:33
> To: Ian Cooper <iancoo...@hotmail.com>; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Fix for missing kernel stack-protector in
> x86_64 glibc builds
>
>
> Does anyone know if we can handle uclibc the same way? It would be nice to
> reduce the special handling in general.
>
> Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
