2018-08-07 10:46:53 -04:00
|
|
|
# Hey Emacs, this is -*- makefile-automake -*- file!
|
|
|
|
|
# vim: filetype=automake
|
|
|
|
|
|
2021-04-21 08:22:18 -04:00
|
|
|
unit-local: check
|
|
|
|
|
|
2022-05-03 05:37:31 -04:00
|
|
|
if HAVE_CMOCKA
|
2021-04-21 08:22:18 -04:00
|
|
|
TESTS = $(check_PROGRAMS)
|
2022-05-03 05:37:31 -04:00
|
|
|
endif HAVE_CMOCKA
|
2021-04-21 08:22:18 -04:00
|
|
|
|
2022-05-03 05:37:31 -04:00
|
|
|
LOG_COMPILER = $(top_builddir)/tests/unit-test-driver.sh
|
2021-04-21 08:22:18 -04:00
|
|
|
|
Avoid using C99 variable length arrays
From an attacker's point of view, a VLA declaration is essentially a
primitive for performing arbitrary arithmetic on the stack pointer. If
the attacker can control the size of a VLA they have a very powerful
tool for causing memory corruption.
To mitigate this kind of attack, and the more general class of stack
clash vulnerabilities, C compilers insert extra code when allocating a
VLA to probe the growing stack one page at a time. If these probes hit
the stack guard page, the program will crash.
From the point of view of a C programmer, there are a few things to
consider about VLAs:
* If it is important to handle allocation failures in a controlled
manner, don't use VLAs. You can use VLAs if it is OK for
unreasonable inputs to cause an uncontrolled crash.
* If the VLA is known to be smaller than some known fixed size,
use a fixed size array and a run-time check to ensure it is large
enough. This will be more efficient than the compiler's stack
probes that need to cope with arbitrary-size VLAs.
* If the VLA might be large, allocate it on the heap. The heap
allocator can allocate multiple pages in one shot, whereas the
stack clash probes work one page at a time.
Most of the existing uses of VLAs in BIND are in test code where they
are benign, but there was one instance in `named`, in the GSS-TSIG
verification code, which has now been removed.
This commit adjusts the style guide and the C compiler flags to allow
VLAs in test code but not elsewhere.
(cherry picked from commit 599c1d2a6b4539bb1f70f5b8a7321311b4bcb60a)
2022-03-18 10:50:36 -04:00
|
|
|
AM_CFLAGS += \
|
2022-05-03 05:37:31 -04:00
|
|
|
-I$(top_srcdir)/tests/include \
|
Avoid using C99 variable length arrays
From an attacker's point of view, a VLA declaration is essentially a
primitive for performing arbitrary arithmetic on the stack pointer. If
the attacker can control the size of a VLA they have a very powerful
tool for causing memory corruption.
To mitigate this kind of attack, and the more general class of stack
clash vulnerabilities, C compilers insert extra code when allocating a
VLA to probe the growing stack one page at a time. If these probes hit
the stack guard page, the program will crash.
From the point of view of a C programmer, there are a few things to
consider about VLAs:
* If it is important to handle allocation failures in a controlled
manner, don't use VLAs. You can use VLAs if it is OK for
unreasonable inputs to cause an uncontrolled crash.
* If the VLA is known to be smaller than some known fixed size,
use a fixed size array and a run-time check to ensure it is large
enough. This will be more efficient than the compiler's stack
probes that need to cope with arbitrary-size VLAs.
* If the VLA might be large, allocate it on the heap. The heap
allocator can allocate multiple pages in one shot, whereas the
stack clash probes work one page at a time.
Most of the existing uses of VLAs in BIND are in test code where they
are benign, but there was one instance in `named`, in the GSS-TSIG
verification code, which has now been removed.
This commit adjusts the style guide and the C compiler flags to allow
VLAs in test code but not elsewhere.
(cherry picked from commit 599c1d2a6b4539bb1f70f5b8a7321311b4bcb60a)
2022-03-18 10:50:36 -04:00
|
|
|
$(TEST_CFLAGS)
|
|
|
|
|
|
2018-08-07 10:46:53 -04:00
|
|
|
AM_CPPFLAGS += \
|
|
|
|
|
$(CMOCKA_CFLAGS) \
|
2022-04-22 07:27:12 -04:00
|
|
|
-DNAMED_PLUGINDIR=\"$(pkglibdir)\" \
|
2021-01-18 13:15:44 -05:00
|
|
|
-DTESTS_DIR=\"$(abs_srcdir)\"
|
2018-08-07 10:46:53 -04:00
|
|
|
|
2022-05-03 22:43:23 -04:00
|
|
|
LDADD += \
|
|
|
|
|
$(top_builddir)/tests/libtest/libtest.la \
|
2018-08-07 10:46:53 -04:00
|
|
|
$(CMOCKA_LIBS)
|