Thank-you Ed. Though I have two questions:
1. We've recompiled all the ports I use with either -fPIC or -fPIE and
the linker flag -pie. Is there something required for ports to utilise
these changes, or are the changes only in the mk files affecting the
base system build?
2. I've also taken advantage of employing -fstack-clash-protection,
unfortunately this is currently only available via gcc (we're using gcc9
at the moment). Does the fact that we use gcc9 and binutils 2.33.1
influence the outcome of your changes?
Regards, Dewayne
PS an interesting aside, there are a surprising number of ports that use
the _FORTIFY_SOURCE=2 so the application developers are well
intentioned, a nice (though futile) effort, because libc doesn't have
the *_chk macros. At least we're all heading in the right direction to
deny malcontents easy unauthorised access. :)
On 5/06/2020 12:23 am, Ed Maste wrote:> Kostik and I recently committed a couple of changes to improve PIE
> binary support:
>
> r361725 Do not allow to load ET_DYN object with DF_1_PIE flag set.
> r361740 lld: Set DF_1_PIE for -pie
>
> Previously there could be ambiguity as to whether an object is a
> shared library (DSO) or Position Independent Executable (PIE) binary;
> a PIE is in fact a special type of DSO. These changes add a .dynamic
> flag DF_1_PIE that's used to unambiguously indicate that an object is
> a PIE binary, and disallow the use of dlopen() or DT_NEEDED on that
> binary.
>
> Future changes should have file(1) report "position independent
> executable" or similar instead of "shared object". Some
desktop
> environments / file managers have had issues refusing to execute PIE
> binaries, and tagging them should also address those.
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at
freebsd.org"
>