Commit graph

9 commits

Author SHA1 Message Date
Kyle Evans
1f155d48f8 include: ssp: fortify <sys/socket.h>
The entire recv*() implementation set is ripe for opportunities to
validate, so do what we can with what we have.

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45686
2024-07-13 00:16:26 -05:00
Kyle Evans
2aba0eea3f include: ssp: fortify <sys/select.h>
Notably sanity check indices passed to the FD_*() macros against the
size of the fd_set itself.

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45685
2024-07-13 00:16:25 -05:00
Kyle Evans
1ace24b30c include: ssp: fortify <sys/uio.h>
Check both the buffer size of the iov object itself, as well as that
of each indidvidually io base.

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45684
2024-07-13 00:16:25 -05:00
Kyle Evans
062d9380b9 include: ssp: fortify <sys/random.h>
That is to say, fortify getrandom(2).

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45683
2024-07-13 00:16:25 -05:00
Kyle Evans
b53d7aa88f include: ssp: fortify <wchar.h>
This includes all of the w*() equivalents to str*()/mem*() implemented
in more or less the same way.  For these ones, we'll just use
header-only implementations from the start to stop further cluttering
the libc symbol table.

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45682
2024-07-13 00:16:25 -05:00
Kyle Evans
d0b7445904 include: ssp: fortify <stdlib.h>
The immediately obvious and attractive targets from <stdlib.h> are
arc4random_buf(3) and realpath(3) -- scraping the header didn't reveal
much else of interest.

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45681
2024-07-13 00:16:24 -05:00
Kyle Evans
88276dfbf1 include: ssp: fortify poll/ppoll from <poll.h>
For poll/ppoll we just need to bounds-check the poll array that we're
about to write out to.

Reviewed by:	kib, markj (earlier version)
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45680
2024-07-13 00:16:24 -05:00
Kyle Evans
cf8e5289a1 include: ssp: round out fortification of current set of headers
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
2024-07-13 00:16:24 -05:00
Kyle Evans
020d003c86 libc: tests: add testing infrastructure for _FORTIFY_SOURCE
The _FORTIFY_SOURCE tests will be generated by a lua script to avoid a
lot of redundancy in writing these tests.  For each function that we're
fortifying, the plan is to test at least the following three scenarios:

 - Writing up to one byte before the end of the buffer,
 - Writing up to the end of the buffer,
 - Writing one byte past the end of the buffer

The buffer is shoved into a struct on the stack to guarantee a stack
layout in which we have a valid byte after the buffer so that level 2
fortification will trip and we can have confidence that it wasn't some
other stack/memory protection instead.

The generated tests are divided roughly into which header we're
attributing them to so that we can parallelize the build -- the full set
is a bit over 9000 lines of C and takes 11s to build on the hardware
that I'm testing on if it's a single monolothic file.

Reviewed by:	markj
Sponsored by:	Klara, Inc.
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D45678
2024-07-13 00:16:23 -05:00