Our vcxproj files set the WarningLevel to Level3, which is too verbose
for a code that needs to be portable. That basically leads to ignoring
all the errors that MSVC produces. This commits downgrades the
WarningLevel to Level1 and enables treating warnings as errors for
Release builds. For the Debug builds the WarningLevel got upgraded to
Level4, and treating warnings as errors is explicitly disabled.
We should eventually make the code clean of all MSVC warnings, but it's
a long way to go for Level4, so it's more reasonable to start at Level1.
For reference[1], these are the warning levels as described by MSVC
documentation:
* /W0 suppresses all warnings. It's equivalent to /w.
* /W1 displays level 1 (severe) warnings. /W1 is the default setting
in the command-line compiler.
* /W2 displays level 1 and level 2 (significant) warnings.
* /W3 displays level 1, level 2, and level 3 (production quality)
warnings. /W3 is the default setting in the IDE.
* /W4 displays level 1, level 2, and level 3 warnings, and all level 4
(informational) warnings that aren't off by default. We recommend
that you use this option to provide lint-like warnings. For a new
project, it may be best to use /W4 in all compilations. This option
helps ensure the fewest possible hard-to-find code defects.
* /Wall displays all warnings displayed by /W4 and all other warnings
that /W4 doesn't include — for example, warnings that are off by
default.
* /WX treats all compiler warnings as errors. For a new project, it
may be best to use /WX in all compilations; resolving all warnings
ensures the fewest possible hard-to-find code defects.
1. https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2019
(cherry picked from commit 789d253e3d)
BIND wasn't honoring option "deny-answer-aliases" when configured to
forward queries.
Before the fix it was possible for nameservers listed in "forwarders"
option to return CNAME answers pointing to unrelated domains of the
original query, which could be used as a vector for rebinding attacks.
The fix ensures that BIND apply filters even if configured as a forwarder
instance.
This is the warning:
In file included from print_test.c:47:
./../print.c:203:9: warning: Although the value stored to 'neg' is used in the enclosing expression, the value is never actually read from 'neg'
dot = neg = space = plus = left = zero = alt = h = l = q = z = 0;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
The 3 warnings reported are:
os.c:872:7: warning: Although the value stored to 'ptr' is used in the enclosing expression, the value is never actually read from 'ptr'
if ((ptr = strtok_r(command, " \t", &last)) == NULL) {
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
--
rpz.c:1117:10: warning: Although the value stored to 'zbits' is used in the enclosing expression, the value is never actually read from 'zbits'
return (zbits &= x);
^ ~
1 warning generated.
--
openssleddsa_link.c:532:10: warning: Although the value stored to 'err' is used in the enclosing expression, the value is never actually read from 'err'
while ((err = ERR_get_error()) != 0) {
^ ~~~~~~~~~~~~~~~
1 warning generated.
(cherry picked from commit 262f087bcf)
The libisc LIBINTERFACE bump for 9.11.17 is unnecessary.
A lot of headers were altered but the ABI tool did not report anything.
Trust the ABI tool on this and decrement LIBINTERFACE and increment
LIBREVISION.
Bumped the version file and added release line in CHANGES.
API files:
- lib/bind9/api:
No changes because only changes in comments.
- lib/dns/api:
Increment LIBINTERFACE because of the added field structure in
dns_struct_update.
- lib/isc/api:
Increment LIBINTERFACE because of the PKCS#11 replacement.
- lib/isccc/api:
No changes because no source code changes.
- lib/isccfg/api:
Increment LIBREVISION because of minor source code changes.
- lib/lwres/api:
No changes because no source code changes.
I decided no changes to README.md or the release notes were necessary.
Perflab graphs look sane.
On Windows, C11 localtime_r() and gmtime_r() functions are not
available. While localtime() and gmtime() functions are already thread
safe because they use Thread Local Storage, it's quite ugly to #ifdef
around every localtime_r() and gmtime_r() usage to make the usage also
thread-safe on POSIX platforms.
The commit adds wrappers around Windows localtime_s() and gmtime_s()
functions.
NOTE: The implementation of localtime_s and gmtime_s in Microsoft CRT
are incompatible with the C standard since it has reversed parameter
order and errno_t return type.
(cherry picked from commit 08f4c7d6c0)
some empty conditional branches which contained a semicolon were
"fixed" by clang-format to contain nothing. add comments to prevent this.
(cherry picked from commit 735be3b816)
Save 'i' to 'locknum' and use that rather than using
'header->node->locknum' when performing the deferred
unlock as 'header->node->locknum' can theoretically be
different to 'i'.
(cherry picked from commit 8dd8d48c9f)
cppcheck 1.90 reports the following false positives for
lib/dns/tests/rbt_serialize_test.c:
lib/dns/tests/rbt_serialize_test.c:412:12: warning: Either the condition 'base!=NULL' is redundant or there is pointer arithmetic with NULL pointer. [nullPointerArithmeticRedundantCheck]
p = base + (r % filesize);
^
lib/dns/tests/rbt_serialize_test.c:407:20: note: Assuming that condition 'base!=NULL' is not redundant
assert_true(base != NULL && base != MAP_FAILED);
^
lib/dns/tests/rbt_serialize_test.c:405:14: note: Assignment 'base=mmap(NULL,filesize,PROT_READ|PROT_WRITE,0|MAP_PRIVATE,fd,0)', assigned value is 0
base = mmap(NULL, filesize, PROT_READ|PROT_WRITE,
^
lib/dns/tests/rbt_serialize_test.c:412:12: note: Null pointer addition
p = base + (r % filesize);
^
lib/dns/tests/rbt_serialize_test.c:413:12: warning: Either the condition 'base!=NULL' is redundant or there is pointer arithmetic with NULL pointer. [nullPointerArithmeticRedundantCheck]
q = base + filesize;
^
lib/dns/tests/rbt_serialize_test.c:407:20: note: Assuming that condition 'base!=NULL' is not redundant
assert_true(base != NULL && base != MAP_FAILED);
^
lib/dns/tests/rbt_serialize_test.c:405:14: note: Assignment 'base=mmap(NULL,filesize,PROT_READ|PROT_WRITE,0|MAP_PRIVATE,fd,0)', assigned value is 0
base = mmap(NULL, filesize, PROT_READ|PROT_WRITE,
^
lib/dns/tests/rbt_serialize_test.c:413:12: note: Null pointer addition
q = base + filesize;
^
This is caused by cppcheck not understanding how cmocka's assert_true()
macro works. The problem being reported is a false positive: if mmap()
fails, the lines flagged by cppcheck will never be reached. Address the
problem by suppressing nullPointerArithmeticRedundantCheck warnings for
the affected lines.
cppcheck 1.90 reports some false positives for lib/dns/client.c:
lib/dns/client.c:1431:2: warning: Either the condition 'rctx==((void*)0)' is redundant or there is possible null pointer dereference: rctx. [nullPointerRedundantCheck]
rctx->rdataset = rdataset;
^
lib/dns/client.c:1416:11: note: Assuming that condition 'rctx==((void*)0)' is not redundant
if (rctx == NULL)
^
lib/dns/client.c:1415:9: note: Assignment 'rctx=isc__mem_get(mctx,sizeof(*rctx),"lib/dns/client.c",1415)', assigned value is 0
rctx = isc_mem_get(mctx, sizeof(*rctx));
^
lib/dns/client.c:1431:2: note: Null pointer dereference
rctx->rdataset = rdataset;
^
lib/dns/client.c:1438:2: warning: Either the condition 'rctx==((void*)0)' is redundant or there is possible null pointer dereference: rctx. [nullPointerRedundantCheck]
rctx->sigrdataset = sigrdataset;
^
lib/dns/client.c:1416:11: note: Assuming that condition 'rctx==((void*)0)' is not redundant
if (rctx == NULL)
^
lib/dns/client.c:1415:9: note: Assignment 'rctx=isc__mem_get(mctx,sizeof(*rctx),"lib/dns/client.c",1415)', assigned value is 0
rctx = isc_mem_get(mctx, sizeof(*rctx));
^
lib/dns/client.c:1438:2: note: Null pointer dereference
rctx->sigrdataset = sigrdataset;
^
lib/dns/client.c:1445:2: warning: Either the condition 'rctx==((void*)0)' is redundant or there is possible null pointer dereference: rctx. [nullPointerRedundantCheck]
rctx->client = client;
^
lib/dns/client.c:1416:11: note: Assuming that condition 'rctx==((void*)0)' is not redundant
if (rctx == NULL)
^
lib/dns/client.c:1415:9: note: Assignment 'rctx=isc__mem_get(mctx,sizeof(*rctx),"lib/dns/client.c",1415)', assigned value is 0
rctx = isc_mem_get(mctx, sizeof(*rctx));
^
lib/dns/client.c:1445:2: note: Null pointer dereference
rctx->client = client;
^
lib/dns/client.c:1827:2: warning: Either the condition 'ctx==((void*)0)' is redundant or there is possible null pointer dereference: ctx. [nullPointerRedundantCheck]
ctx->client = client;
^
lib/dns/client.c:1815:10: note: Assuming that condition 'ctx==((void*)0)' is not redundant
if (ctx == NULL)
^
lib/dns/client.c:1814:8: note: Assignment 'ctx=isc__mem_get(client->mctx,sizeof(*ctx),"lib/dns/client.c",1814)', assigned value is 0
ctx = isc_mem_get(client->mctx, sizeof(*ctx));
^
lib/dns/client.c:1827:2: note: Null pointer dereference
ctx->client = client;
^
All of them are caused by cppcheck not recognizing the relationship
between isc_mem_get() returning NULL and the result variable being set
to ISC_R_NOMEMORY (with a subsequent jump to a cleanup section).
Move "goto cleanup;" statements into error handling branches to prevent
cppcheck from generating these warnings.
cppcheck 1.89 enabled certain value flow analysis mechanisms [1] which
trigger null pointer dereference false positives that were previously
not reported. It seems that cppcheck no longer treats at least some
REQUIRE() assertion failures as fatal, so add extra assertion macro
definitions to lib/isc/include/isc/util.h that are only used when the
CPPCHECK preprocessor macro is defined; these definitions make cppcheck
1.89 behave as expected.
There is an important requirement for these custom definitions to work:
cppcheck must properly treat abort() as a function which does not
return. In order for that to happen, the __GNUC__ macro must be set to
a high enough number (because system include directories are used and
system headers compile attributes away if __GNUC__ is not high enough).
__GNUC__ is thus set to the major version number of the GCC compiler
used, which is what that latter does itself during compilation.
[1] aaeec462e6
(cherry picked from commit abfde3d543)
zone_needdump() could potentially not call zone_settimer() so
explitly call zone_settimer() as zone->resigntime could have
gone backward.
(cherry picked from commit 5ec57f31b0)
With RRSIG records no longer being signed with the full
sig-validity-interval we need to ensure the zone->resigntime
as it may need to be set to a earlier time.
(cherry picked from commit 5d1611afdc)
* CKR_CRYPTOKI_ALREADY_INITIALIZED: This value can only be returned by
`C_Initialize`. It means that the Cryptoki library has already been
initialized (by a previous call to `C_Initialize` which did not have a
matching `C_Finalize` call).
* CKR_FUNCTION_NOT_SUPPORTED: The requested function is not supported by this
Cryptoki library. Even unsupported functions in the Cryptoki API should have a
"stub" in the library; this stub should simply return the value
CKR_FUNCTION_NOT_SUPPORTED.
* CKR_LIBRARY_LOAD_FAILED: The Cryptoki library could not load a dependent
shared library.
(cherry picked from commit f6922d6e78)
The OASIS pkcs11.h header has a restrictive license. Replace the
pkcs11.h pkcs11f.h and pkcs11t.h headers with pkcs11.h from p11-kit.
For source distribution, the license for the OASIS headers itself
doesn't pose any licensing problem when combined with MPL license, but
it possibly creates problem for downstream distributors of BIND 9.
(cherry picked from commit c47fad2431)
* ctx needs to be destroyed before it is regenerated.
* emit the name of the signature to be replaced.
* cleanup memory before asserting so post longjump doesn't detect a
memory leak.
* comment code.
(cherry picked from commit 3a8c8a2a31)
The memory ordering in the rwlock was all wrong, I am copying excerpts
from the https://en.cppreference.com/w/c/atomic/memory_order#Relaxed_ordering
for the convenience of the reader:
Relaxed ordering
Atomic operations tagged memory_order_relaxed are not synchronization
operations; they do not impose an order among concurrent memory
accesses. They only guarantee atomicity and modification order
consistency.
Sequentially-consistent ordering
Atomic operations tagged memory_order_seq_cst not only order memory
the same way as release/acquire ordering (everything that
happened-before a store in one thread becomes a visible side effect in
the thread that did a load), but also establish a single total
modification order of all atomic operations that are so tagged.
Which basically means that we had no or weak synchronization between
threads using the same variables in the rwlock structure. There should
not be a significant performance drop because the critical sections were
already protected by:
while(1) {
if (relaxed_atomic_operation) {
break;
}
LOCK(lock);
if (!relaxed_atomic_operation) {
WAIT(sem, lock);
}
UNLOCK(lock)l
}
I would add one more thing to "Don't do your own crypto, folks.":
- Also don't do your own locking, folks.
As part of this commit, I have also cleaned up the #ifdef spaghetti,
and fixed the isc_atomic API usage.
The ThreadSanitizer found several possible data races in our rwlock
implementation. This commit convert .spins and .write_granted fields
to atomic.
(cherry picked from commit 1da0994ea4)
The code for specifying OpenSSL PKCS#11 engine as part of the label
(e.g. -l "pkcs11:token=..." instead of -E pkcs11 -l "token=...")
was non-functional. This commit just cleans the related code.
(cherry picked from commit a5c87d9d18)
