summaryrefslogtreecommitdiff
path: root/libpthread/nptl/alloca_cutoff.c
diff options
context:
space:
mode:
authorhanishkvc <hanishkvc@gmail.com>2022-05-11 02:44:43 +0530
committerWaldemar Brodkorb <wbx@openadk.org>2022-05-12 06:02:40 +0200
commitf73fcb3d067e22817189077c9b7bd2417c930d34 (patch)
treec3b511fdca4b33a2269943d53e0437065b55c11f /libpthread/nptl/alloca_cutoff.c
parent592574ae535c35de500f6c3e8d8400d0bb0d985a (diff)
DnsLookup: Configurable dnsQueryId generation including random
Dns lookup logic has been updated to provide a configurable compile time selection of dns query id generation logics, including random, where possible, instead of the previous simple counter mode. This should make dns poison attempts more difficult. The uclibc developers wish to thank the white hat teams which alerted the community about the possible weakness in the dns path, given the increased resources with adversaries today. Given that embedded systems may or may not have sources for trying to generate random numbers, and also to try and keep the load on the system low, by default it uses the standard random prng based logic to indirectly generate the ids. However if either urandom or else if realtime clock is available on the target, then the same is used to reseed the prng periodically in a slightly non deterministic manner. Also additional transform (one way where possible) is used to avoid directly exposing the internal random sequence. The dns lookup logic maintains its own state wrt the random prng functions, so that other users of the library's random prng are not affected wrt their operations with the prng. Note to Platform developers: If you want to change from the default prngplus based logic, to one of the other logics provided, then during compile/config time you can switch to one of these additional choices wrt dns query id generation, by using make config and companions. If your platform doesnt support urandom nor a realtime clock backed by a source with sufficient resolution, and or for some reason if you want to revert to previous simple counter, rather than the transformed random prng plus logic, you can force the same at compile time by selecting SimpleCounter mode. If you want to increase the randomness of the generated ids, and dont mind the increased system load and latency then you could select the Urandom mode during config. Do note that it will be dipping into the entropy pool maintained by ur system. If your target has a system realtime clock available and exposed to user space, and inturn if you want to keep the underlying logic simple, you could try using the clock option from the config. However do note that the clock should have nanosecond resolution to help generate ids which are plausibly random. Also improvements to processor and or io performance can affect this. Wrt the URandom and Clock modes, if there is a failure with generation of the next random value, the logic tries to fallback to simple counter mode. If you want to change the underlying logic to make it more random and or more simple, look at dnsrand_setup and dnsrand_next. Signed-off-by: hanishkvc <hanishkvc@gmail.com>
Diffstat (limited to 'libpthread/nptl/alloca_cutoff.c')
0 files changed, 0 insertions, 0 deletions