Re: urandom seed with random id against dns poison and pre increment local_id for fallback to old simple counter behavior
Hi,
Have updated the logic further such that
a platform developer can force dnsrand_next to help achieve the current/previous simple counter logic, if needed.
However if random dns query id is desired, then if urandom reading fails (previously it would have fallen back to the simple counter) but in turn if real time clock is available then clock_gettime is used to help reseed through srandom. However if neither (ie urandom and clock) is available, then now it still continues with the random prng, bcas anyway it is better than the simple counter at some level.
Attached is the format-patch output between glibc master (592574ae535c35de500f6c3e8d8400d0bb0d985a) till the latest flow from my side.
Hi Hanish,
thanks for working on a solution. Can you squash your latest work into one commit and add a good commit message to it. Please use git format-patch -s to generate a Signed-Off-By Tag.
best regards Waldemar
C Hanish Menon wrote,
Hi,
Have updated the logic further such that
a platform developer can force dnsrand_next to help achieve the current/ previous simple counter logic, if needed.
However if random dns query id is desired, then if urandom reading fails (previously it would have fallen back to the simple counter) but in turn if real time clock is available then clock_gettime is used to help reseed through srandom. However if neither (ie urandom and clock) is available, then now it still continues with the random prng, bcas anyway it is better than the simple counter at some level.
Attached is the format-patch output between glibc master (592574ae535c35de500f6c3e8d8400d0bb0d985a) till the latest flow from my side.
-- Keep ;-) HanishKVC
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi Waldemar,
Will send you the squashed single patch. Please do cross check it once just to be sure that I havent overlooked anything obvious.
Hello,
I've done a quick review of your patches
* DNSRAND_FORCE_SIMPLECOUNTERMODE needs to be configurable, have a look at how it's done in extra/Configs/Config.in so that users don't need to actually modify the source code to tweak this feature while building their toolchain.
* is it a good idea to actually call srandom from the libc itself?
What about if the user already called srandom on some precise seed and expects it to stay that way? (For instance in order to have a reproducible random sequence)
What about if the user provided seed was of better "quality"?
* Only do the open("/dev/urandom") if urand_fd != -1 in dnsrand_setup().
* Try to respect the same coding style as the remaining parts of the file
* declare variables at beginning of the function or at the beginning of the code block { }
* do not put "return" on the same line as the "if", put it on next line with proper indentation
* put spaces around % binary operator
How is this done in musl? in glibc?
Maybe we can have a look and take inspiration from there.
Yann
Le 05/05/2022 à 18:51, hanishkvc@gmail.com a écrit :
Hi Waldemar,
Will send you the squashed single patch. Please do cross check it once just to be sure that I havent overlooked anything obvious. _______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org
Hi,
Agreed that it is ideal to have user config wrt FORCE_SIMPLECOUNTERMODE.
You do raise a important point wrt srandom, ie if developer is already using the c random prng for some predictable sequencing of their own logic. But then the issue remains independent of srandom, ie even use of just random at our end will mess with the programs predictable sequence, unless they are using srandom_r and random_r. So better to use srandom_r and random_r with its own context wrt the dns lookup logic, so that we dont step on any other users of the global prng by a application.
dnsrand_setup gets called only once, bcas of the way dns_lookup uses its already existing static variables and the flow around it.
Given that embedded systems could may or maynot have urandom as well as realtime clock (and or might have been disabled), so I have tried to rig up a flow which potentially works across multiple possible configurations by default. But otherwise another developer had responded to my patch by mentioning about musl using clock_gettime, but then such a flow would restrict things to only those builds which have realtime clock enabled.
Can understand the desire to maintain coding styles, being new to uclibc in recent times and also given that my 1st goal was to try and put some ideas around possible paths and or a patch, for anyone who may want one fast, coding style wasnt in my sight. However I will keep the two points which you have mentioned in my sight for the patch I will put out tomorrow.
Hi,
Ignore my point wrt dnsrand_setup, I see the issue.
-
C Hanish Menon -
hanishkvc＠gmail.com
-
Waldemar Brodkorb -
Yann Sionneau