Fix imprecise ordering of SSP canary initializationSubmitted by: Kyle EvansApproved by: soSecurity: FreeBSD-EN-20:01.ssp
Carefully update stack guard bytes inside __guard_setup().This is necessary to make sure that functions that can have stackprotection are not used to update the stack guard. If not, the stackguar
Carefully update stack guard bytes inside __guard_setup().This is necessary to make sure that functions that can have stackprotection are not used to update the stack guard. If not, the stackguard check would fail when it shouldn't.guard_setup() calls elf_aux_info(), which, in turn, calls memcpy() toupdate stack_chk_guard. If either elf_aux_info() or memcpy() havestack protection enabled, __stack_chk_guard will be modified beforereturning 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 PiresMFC after: 1 weekDifferential revision: https://reviews.freebsd.org/D15173
show more ...
libc: do not include <sys/types.h> where <sys/param.h> was already includedAccording 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 includedAccording 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).
libc: don't build compat functions if building WITHOUT_SYMVERWITHOUT_SYMVER necessarily implies building a system without symverbackwards compatability.Sponsored by: The FreeBSD Foundation
Remove a stale comment and clarify the original where it was taken fromThe comment in the libc/sys symbol map referenced the generated symbolsfor the syscall trampolines. Such comment was out of p
Remove a stale comment and clarify the original where it was taken fromThe comment in the libc/sys symbol map referenced the generated symbolsfor the syscall trampolines. Such comment was out of place in the securesymbol map so remove the stale comment and attempt to clarify the old oneto avoid risks of confusion.Pointed out by: kib
Move the stack protector to a new "secure" directoryAs part of the code refactoring to support FORTIFY_SOURCE we wanta new subdirectory "secure" to keep the files related to security.Move the sta
Move the stack protector to a new "secure" directoryAs part of the code refactoring to support FORTIFY_SOURCE we wanta 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