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.
S

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

show more ...

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: Storm

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

show more ...

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: Stor

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

show more ...

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/

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

show more ...

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

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

show more ...

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.

Rev

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

show more ...

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: K

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

show more ...

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 w

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

show more ...