aboutsummaryrefslogtreecommitdiff
path: root/lib/libc/secure
Commit message (Collapse)AuthorAgeFilesLines
* libmd, kern, stand: consolidate md5 implementations (NFC)Kyle Evans2024-09-302-1/+1
| | | | | | | | | | | | | | | | | | | | | Reduce the number of md5c.c between the three of these from two to one by just reaching into the kernel build for both userland builds. The precedent for this already exists for sha2 in both cases. _libmd_ symbol privatization bits have been moved to sys/md5.h and md5.h remains to #include <sys/md5.h> for compatibility. This stops exporting MD5Pad() in the process because the kernel stopped exporting it in 502a35d60f4c. soversion is bumped accordingly. This also renames the libc version of stack_protector.c; it previously only worked by coincidence because .PATH ordering worked out such that we got the right one, but this is not the case anymore. Remove the landmine. PR: 280784 (exp-run) Reviewed by: allanjude, delphij Differential Revision: https://reviews.freebsd.org/D34497
* include: ssp: don't shadow the mempcpy builtinKyle Evans2024-07-163-1/+51
| | | | | | | | | | | GCC emits a warning about shadowing a builtin with our mempcpy declaration, so switch it to using the same model as memcpy() and use the apparently-existing __builtin___mempcpy_chk(). Reviewed by: kib (earlier version), markj Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D45976
* include: ssp: round out fortification of current set of headersKyle Evans2024-07-134-2/+117
| | | | | | | | | | | | | | | | | | | | ssp/ssp.h needed some improvements: - `len` isn't always a size_t, it may need casted - In some cases we may want to use a len that isn't specified as a parameter (e.g., L_ctermid), so __ssp_redirect() should be more flexible. - In other cases we may want additional checking, so pull all of the declaration bits out of __ssp_redirect_raw() so that some functions can implement the body themselves. strlcat/strlcpy should be the last of the fortified functions that get their own __*_chk symbols, and these cases are only done to be consistent with the rest of the str*() set. Reviewed by: markj Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D45679
* include: de-macro __ssp_overlap(), improve semantics and checkingKyle Evans2024-07-131-1/+1
| | | | | | | | | | | | | | | Switch away from pointer arithmetic to provide more obvious semantics for checking overlap on pointer ranges. This lets us remove some casts that need not exist and removes some possible fragility in its use. While we're here, check for overflow just in case; sometimes we use a caller-supplied size if __builtin_object_size(3) can't deduce the buffer size, and we should fail the check if the size is nonsensical for the provided buffers. Reviewed by: markj Sponsored by: Klara, Inc. Sponsored by: Stormshield
* libc: move __ssp_overlap back out into <ssp/ssp.h>Kyle Evans2024-07-136-47/+0
| | | | | | | | | | | | We'll be using it in some upcoming definitions in headers, so move it back now but slap a warning on it. Our upcoming uses will all be inside of inline functions, so we're not overly concerned about double evaluation immediately. Reviewed by: markj Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D45677
* Fix the GCC build after _FORTIFY_SOURCE importKyle Evans2024-05-133-76/+1
| | | | | We haven't exposed gets(3) in a long time, rip out __gets_chk before it's too late and something builds a gets(3) user with it enabled.
* Import _FORTIFY_SOURCE implementation from NetBSDKyle Evans2024-05-1318-0/+909
| | | | | | | | | | | | This is a mostly-unmodified copy of the various *_chk implementations and headers from NetBSD, without yet modifying system headers to start actually including them. A future commit will also apply the needed bits to fix ssp/unistd.h. Reviewed by: imp, pauamma_gundo.com (both previous versions), kib Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D32306
* libc: Remove empty comments in Symbol.mapBrooks Davis2023-11-151-3/+0
| | | | | | | These were left over from $FreeBSD$ removal. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D42612
* libc: Purge unneeded cdefs.hWarner Losh2023-11-011-1/+0
| | | | | | | | | These sys/cdefs.h are not needed. Purge them. They are mostly left-over from the $FreeBSD$ removal. A few in libc are still required for macros that cdefs.h defines. Keep those. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D42385
* Remove $FreeBSD$: one-line sh patternWarner Losh2023-08-161-1/+0
| | | | Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
* Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-162-4/+0
| | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* Remove $FreeBSD$: one-line .h patternWarner Losh2023-08-161-1/+0
| | | | Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
* libc: ssp: remove some GCC 4.2 remnantsKyle Evans2023-02-101-9/+1
| | | | | | | | With GCC 4.2 out of the tree for a while now and no sign of it returning, we don't really need to support older versions that don't allow us to specify a ctor priority anymore. Noticed by: mjg
* libc: ssp: sprinkle around some __dead2Kyle Evans2021-10-011-3/+3
| | | | | This is consistent with, e.g., NetBSD's implementation, which declares these as noreturn in ssp/ssp.h.
* Remove the SYMVER build option.John Baldwin2020-04-301-4/+2
| | | | | | | | | | | | | | This option was added as a transition aide when symbol versioning was first added. It was enabled by default in 2007 and is supported even by the old GPLv2 binutils. Trying to disable it currently fails to build in libc and at this point it isn't worth fixing the build. Reported by: Michael Dexter Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D24637 Notes: svn path=/head/; revision=360511
* ssp: knock out some trivial warnings that come up with WARNS=6Kyle Evans2020-01-041-3/+5
| | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=356355
* ssp: further refine the conditional used for constructor priorityKyle Evans2019-11-131-1/+1
| | | | | | | | | | | | __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. Notes: svn path=/head/; revision=354689
* ssp: rework the logic to use priority=200 on clang buildsKyle Evans2019-11-131-4/+6
| | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=354672
* ssp: add a priority to the __stack_chk_guard constructorKyle Evans2019-11-131-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=354669
* Carefully update stack guard bytes inside __guard_setup().Konstantin Belousov2018-04-241-4/+16
| | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=332940
* libc: do not include <sys/types.h> where <sys/param.h> was already includedAndriy Voskoboinyk2016-04-181-1/+0
| | | | | | | | | 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). Notes: svn path=/head/; revision=298226
* libc: don't build compat functions if building WITHOUT_SYMVEREd Maste2016-03-151-3/+4
| | | | | | | | | | WITHOUT_SYMVER necessarily implies building a system without symver backwards compatability. Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=296915
* Remove a stale comment and clarify the original where it was taken fromPedro F. Giffuni2015-08-141-5/+0
| | | | | | | | | | | | The comment in the libc/sys symbol map referenced the generated symbols for the syscall trampolines. Such comment was out of place in the secure symbol map so remove the stale comment and attempt to clarify the old one to avoid risks of confusion. Pointed out by: kib Notes: svn path=/head/; revision=286782
* Move the stack protector to a new "secure" directoryPedro F. Giffuni2015-08-144-0/+163
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 Notes: svn path=/head/; revision=286760
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 17:32:10 +0000