libc: ssp: sprinkle around some __dead2

This is consistent with, e.g., NetBSD's implementation, which declares
these as noreturn in ssp/ssp.h.

(cherry picked from commit 5487294d79f9ebe72a847d0855a

libc: ssp: sprinkle around some __dead2

This is consistent with, e.g., NetBSD's implementation, which declares
these as noreturn in ssp/ssp.h.

(cherry picked from commit 5487294d79f9ebe72a847d0855adb4df85e0d66e)

show more ...

ssp: knock out some trivial warnings that come up with WARNS=6

A future commit will rebuild this as part of libssp. The exact warnings are
fairly trivially fixed:
- No previous declaration for __sta

ssp: knock out some trivial warnings that come up with WARNS=6

A future commit will rebuild this as part of libssp. The exact warnings are
fairly trivially fixed:
- No previous declaration for __stack_chk_guard
- idx is the wrong type, nitems yields a size_t
- Casting away volatile on the tmp_stack_chk_guard directly is a no-no.

Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22943

show more ...

ssp: further refine the conditional used for constructor priority

__has_attribute(__constructor__) is a better test for clang than
defined(__clang__). Switch to it instead.

While we're already here

ssp: further refine the conditional used for constructor priority

__has_attribute(__constructor__) is a better test for clang than
defined(__clang__). Switch to it instead.

While we're already here and touching it, pfg@ nailed down when GCC actually
introduced the priority argument -- 4.3. Use that instead of our
hammer-guess of GCC >= 5 for the sake of correctness.

show more ...

ssp: rework the logic to use priority=200 on clang builds

The preproc logic was added at the last minute to appease GCC 4.2, and
kevans@ did clearly not go back and double-check that the logic worke

ssp: rework the logic to use priority=200 on clang builds

The preproc logic was added at the last minute to appease GCC 4.2, and
kevans@ did clearly not go back and double-check that the logic worked out
for clang builds to use the new variant.

It turns out that clang defines __GNUC__ == 4. Flip it around and check
__clang__ as well, leaving a note to remove it later.

Reported by: cem

show more ...

ssp: add a priority to the __stack_chk_guard constructor

First, this commit is a NOP on GCC <= 4.x; this decidedly doesn't work
cleanly on GCC 4.2, and it will be gone soon anyways so I chose not to

ssp: add a priority to the __stack_chk_guard constructor

First, this commit is a NOP on GCC <= 4.x; this decidedly doesn't work
cleanly on GCC 4.2, and it will be gone soon anyways so I chose not to dump
time into figuring out if there's a way to make it work. xtoolchain-gcc,
clocking in as GCC6, can cope with it just fine and later versions are also
generally ok with the syntax. I suspect very few users are running GCC4.2
built worlds and also experiencing potential fallout from the status quo.

For dynamically linked applications, this change also means very little.
rtld will run libc ctors before most others, so the situation is
approximately a NOP for these as well.

The real cause for this change is statically linked applications doing
almost questionable things in their constructors. qemu-user-static, for
instance, creates a thread in a global constructor for their async rcu
callbacks. In general, this works in other places-

- On OpenBSD, __stack_chk_guard is stored in an .openbsd.randomdata section
that's initialized by the kernel in the static case, or ld.so in the
dynamic case
- On Linux, __stack_chk_guard is apparently stored in TLS and such a problem
is circumvented there because the value is presumed stable in the new
thread.

On FreeBSD, the rcu thread creation ctor and __guard_setup are both unmarked
priority. qemu-user-static spins up the rcu thread prior to __guard_setup
which starts making function calls- some of these are sprinkled with the
canary. In the middle of one of these functions, __guard_setup is invoked in
the main thread and __stack_chk_guard changes- qemu-user-static is promptly
terminated for an SSP violation that didn't actually happen.

This is not an all-too-common problem. We circumvent it here by giving the
__stack_chk_guard constructor a solid priority. 200 was chosen because that
gives static applications ample range (down to 101) for working around it
if they really need to. I suspect most applications will "just work" as
expected- the default/non-prioritized flavor of __constructor__ functions
run last, and the canary is generally not expected to change as of this
point at the very least.

This took approximately three weeks of spare time debugging to pin down.

PR: 241905

show more ...

Carefully update stack guard bytes inside __guard_setup().

This is necessary to make sure that functions that can have stack
protection are not used to update the stack guard. If not, the stack
guar

Carefully update stack guard bytes inside __guard_setup().

This is necessary to make sure that functions that can have stack
protection are not used to update the stack guard. If not, the stack
guard check would fail when it shouldn't.

guard_setup() calls elf_aux_info(), which, in turn, calls memcpy() to
update stack_chk_guard. If either elf_aux_info() or memcpy() have
stack protection enabled, __stack_chk_guard will be modified before
returning from them, causing the stack protection check to fail.

This change uses a temporary buffer to delay changing
__stack_chk_guard until elf_aux_info() returns.

Submitted by: Luis Pires
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D15173

show more ...

libc: do not include <sys/types.h> where <sys/param.h> was already included

According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <

libc: do not include <sys/types.h> where <sys/param.h> was already included

According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <sys/types.h> when LOCORE is not defined).

show more ...

Move the stack protector to a new "secure" directory

As part of the code refactoring to support FORTIFY_SOURCE we want
a new subdirectory "secure" to keep the files related to security.
Move the sta

Move the stack protector to a new "secure" directory

As part of the code refactoring to support FORTIFY_SOURCE we want
a new subdirectory "secure" to keep the files related to security.
Move the stack protector functions to this new directory.

No functional change.

Differential Review: https://reviews.freebsd.org/D3333

show more ...