On Tue, May 9, 2023 at 7:48 PM Rich Felker <dal...@libc.org> wrote: > On Tue, May 09, 2023 at 07:33:40PM +0200, Denys Vlasenko wrote: > > On Sat, Oct 8, 2022 at 7:23 PM Uwe Kleine-König <u...@kleine-koenig.org> > > wrote: > > > > > > The transaction IDs generated by res_mkquery() for both glibc and musl > > > only > > > depends on the state of the monotonic clock. > > > > Hmm... did you report this to them? > > Yes. It's not a fixable "problem" -- the libc res_mkquery can't know > when or in what context the caller intends to use the packet it > produces, so it can't be responsible for guaranteeing it can't have an > id collision. The space is way too small to avoid collisions in any > case. If we went out of our way (going stateful) to make the assigned > ids more sequential (not "independent"), we'd just be reducing the > (already weak) unpredictability without gaining a useful property.
You miss the point. CLOCK_MONOTONIC may simply be too granular on some hardware - returning the same value for the duration of several milliseconds. In this case, musl's IDs will be the same for successive calls of res_mkquery() - not simply "insufficiently random". Maybe hash in the message bytes in addition to using current nanoseconds? (While we are at it. There is a *signed* division by 256 in the code, intended to mean "take the second byte": int id; ... chars[0] = id / 256; gcc quite often does NOT convert signed divisions to a simple shift. Maybe change id's type to "unsigned"? ). _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
