Fix imprecise ordering of SSP canary initialization

Submitted by:	Kyle Evans
Approved by:	so
Security:	FreeBSD-EN-20:01.ssp

1 files changed, 19 insertions, 1 deletions

diff --git a/lib/libc/secure/stack_protector.c b/lib/libc/secure/stack_protector.c
index 34bb7d0332a3..63c02cd96033 100644
--- a/lib/libc/secure/stack_protector.c
+++ b/lib/libc/secure/stack_protector.c
@@ -40,11 +40,29 @@ __FBSDID("$FreeBSD$");
 #include <unistd.h>
 #include "libc_private.h"
 
+/*
+ * We give __guard_setup a defined priority early on so that statically linked
+ * applications have a defined priority at which __stack_chk_guard will be
+ * getting initialized.  This will not matter to most applications, because
+ * they're either not usually statically linked or they simply don't do things
+ * in constructors that would be adversely affected by their positioning with
+ * respect to this initialization.
+ *
+ * This conditional should be removed when GCC 4.2 is removed.
+ */
+#if __has_attribute(__constructor__) || __GNUC_PREREQ__(4, 3)
+#define	_GUARD_SETUP_CTOR_ATTR	 \
+    __attribute__((__constructor__ (200), __used__));
+#else
+#define	_GUARD_SETUP_CTOR_ATTR	\
+    __attribute__((__constructor__, __used__));
+#endif
+
 extern int __sysctl(const int *name, u_int namelen, void *oldp,
     size_t *oldlenp, void *newp, size_t newlen);
 
 long __stack_chk_guard[8] = {0, 0, 0, 0, 0, 0, 0, 0};
-static void __guard_setup(void) __attribute__((__constructor__, __used__));
+static void __guard_setup(void) _GUARD_SETUP_CTOR_ATTR;
 static void __fail(const char *);
 void __stack_chk_fail(void);
 void __chk_fail(void);