freebsd-skq

History

erj d094320e24 bitstring: exit early if _start is past size of the bitstring bit_ffs_at and bit_ffc_at both take _start parameters which indicate to start searching from _start onwards. If the given _start index is past the size of the bit string, these functions will calculate an address of the current bitstring which is after the expected size. The function will also dereference the memory, resulting in a read buffer overflow. The output of the function remains correct, because the tests ensure to stop the loop if the current bitstring chunk passes the stop bitstring chunk, and because of a check to ensure the reported _value is never past _nbits. However, if <sys/bitstring.h> is ever used in code which is checked by -fsanitize=undefined, or similar static analysis, it can produce warnings about reading past the buffer size. Because of the above mentioned checks, these buffer overflows do not occur as long as _start is less than _nbits. Additionally, by definition bit_ffs_at and bif_ffc_at should set _result to -1 in any case where the _start is after the _nbits. Check for this case at the start of the function and exit early if so, preventing the buffer read overflow, and reducing the amount of computation that occurs. Note that it may seem odd to ever have code that could call bit_ffc_at or bit_ffs_at with a _start value greater than _nbits. However, consider a for-loop that used bit_ffs and bit_ffs_at to loop over a bit string and perform some operation on each bit that was set. If the last bit of the bit string was set, the simplest loop implementation would call bit_ffs_at with a start of _nbits, and expect that to return -1. While it does infact perform correctly, this is what ultimately triggers the unexpected buffer read overflow. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Submitted by: Jacob Keller <jacob.e.keller@intel.com> Reviewed by: asomers@, erj@ MFC after: 1 week Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D22398		2019-11-21 19:36:11 +00:00
..
etc	Add supporting changes for `Add limited sandbox capability to "make check"`	2017-08-14 19:21:37 +00:00
freebsd_test_suite	Fix sys/opencrypto/blake2_test when kern.cryptodevallowsoft=0	2018-08-16 23:49:56 +00:00
sys	bitstring: exit early if _start is past size of the bitstring	2019-11-21 19:36:11 +00:00
Kyuafile
Makefile	Use MK_CHECK_USE_SANDBOX in tests/..., to deal with the fact that	2017-08-02 22:24:08 +00:00
Makefile.depend	DIRDEPS_BUILD: Connect MK_TESTS.	2016-03-09 22:46:01 +00:00
Makefile.inc0	Use bsd.opts.mk, not src.opts.mk	2017-08-03 00:35:35 +00:00
README	Copy README into /usr/tests	2015-11-20 03:24:04 +00:00

README

src/tests: The FreeBSD test suite
=================================

To run the FreeBSD test suite:
(1)  Make sure that kyua is installed:
       pkg install kyua
(2)  To run the tests:
       kyua test -k /usr/tests/Kyuafile
(3)  To see the test results:
       kyua report  

For further information on using the test suite, read tests(7):
       man tests

Description of FreeBSD test suite
=================================
The build of the test suite is organized in the following manner:

* The build of all test artifacts is protected by the MK_TESTS knob.
  The user can disable these with the WITHOUT_TESTS setting in
  src.conf(5).

* The goal for /usr/tests/ (the installed test programs) is to follow
  the same hierarchy as /usr/src/ wherever possible, which in turn drives
  several of the design decisions described below.  This simplifies the
  discoverability of tests.  We want a mapping such as:

    /usr/src/bin/cp/      -> /usr/tests/bin/cp/
    /usr/src/lib/libc/    -> /usr/tests/lib/libc/
    /usr/src/usr.bin/cut/ -> /usr/tests/usr.bin/cut/
    ... and many more ...

* Test programs for specific utilities and libraries are located next
  to the source code of such programs.  For example, the tests for the
  src/lib/libcrypt/ library live in src/lib/libcrypt/tests/.  The tests/
  subdirectory is optional and should, in general, be avoided.

* The src/tests/ hierarchy (this directory) provides generic test
  infrastructure and glue code to join all test programs together into
  a single test suite definition.

* The src/tests/ hierarchy also includes cross-functional test programs:
  i.e. test programs that cover more than a single utility or library
  and thus don't fit anywhere else in the tree.  Consider this to follow
  the same rationale as src/share/man/: this directory contains generic
  manual pages while the manual pages that are specific to individual
  tools or libraries live next to the source code.

In order to keep the src/tests/ hierarchy decoupled from the actual test
programs being installed --which is a worthy goal because it simplifies
the addition of new test programs and simplifies the maintenance of the
tree-- the top-level Kyuafile does not know which subdirectories may
exist upfront.  Instead, such Kyuafile automatically detects, at
run-time, which */Kyuafile files exist and uses those directly.

Similarly, every directory in src/ that wants to install a Kyuafile to
just recurse into other subdirectories reuses this Kyuafile with
auto-discovery features.  As an example, take a look at src/lib/tests/
whose sole purpose is to install a Kyuafile into /usr/tests/lib/.
The goal in this specific case is for /usr/tests/lib/ to be generated
entirely from src/lib/.

-- 
$FreeBSD$