4 May
2022
4 May
'22
9:36 p.m.
Hi,
As noted in the last message, this patch uses the combination of
/dev/urandom + user space random.
Here /dev/urandom periodically (once every 128 random calls) seeds user
space using srandom. Inturn user space random prng is used to generate the
dns query id.
Attached is
a) the full patch wrt uclibc master
(592574ae535c35de500f6c3e8d8400d0bb0d985a), as well as
b) the delta patch wrt my last patch
(patch_20220505IST0032_urandomid_against_dnspoison.patch)
Based on thoughts from others also either the simple urandom only or this
urandom+random based solution could be used against the dns poison issue.
Or may be others might have some other strategy in mind.
Please do note that this is currently only tested on a x86 linux virtual
machine+container environment, by using uclibc-ng and standard linux gcc
build setup (coerced to use uclibc-ng by disabling standard includes and
passing header paths and libs manually to gcc and inturn verifying the
random id using tcpdump and dprints). So testing against other setups would
be useful. At a high level chances are on linux or freebsd or similar
targets, hopefully the patch should be fine, as it uses only /dev/urandom,
srandom and random mainly.
--
Keep ;-)
HanishKVC