These are chat archives for CZ-NIC/knot-resolver

4th
Aug 2017
Vladimír Čunát
@vcunat
Aug 04 2017 05:03
I don' think so. There's just a single generator state for the whole process, seeded from a system file on first use. Every parameter is hardcoded.
Vladimír Čunát
@vcunat
Aug 04 2017 05:34
@nakame_maiku_twitter: actually, there's a bug in initialization of the seed that's triggered in OS-dependent way. (Based on whether the random file is read in a single fread call or not.)
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 06:09
saw the commit, ill recompile and give it another run :)
Vladimír Čunát
@vcunat
Aug 04 2017 06:10
@nakame_maiku_twitter: no, that's not the one.
I haven't noticed that seeding problem yesterday; I'll ping you when I have a commit later today.
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 06:11
ok cool
I do hope this was the thing causing your high entropy loss.
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 08:12
something broke with policy for me
any idea why this might happen?: error: /lib/kdns_modules/policy.lua:237: bad argument #1 to 'match' (aho-corasick expected, got table)
line number might be off as i added a function in there somewhere
I don't use policy.suffix anywhere thoguh
Vladimír Čunát
@vcunat
Aug 04 2017 08:15
policy.suffix is used for special domains that have default answers defined by RFCs
I suppose it's some problem/collision with your custom aho-corasick update?
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 08:18
custom one is 'ahocorasick' without the hyphen, but reviewing my patch file to make sure it doesnt touch anything else
Vladimír Čunát
@vcunat
Aug 04 2017 08:19
BTW, we do have our code for aho-corasick update, but it's not in master yet: https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/337 (expected for 1.4.0 release further in future)
Vladimír Čunát
@vcunat
Aug 04 2017 09:07
Anyway, for testing the impact of entropy loss you don't need the policy module at all. (most likely, depending on your setup)
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 09:20
If I recall, I think the main reason I went with the other ahocorasick code was because of this same issue
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 09:29
results of 5 tests: .34 .45 .43 .47 .45
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 09:50
shouldn't there be a read call here?: openat(AT_FDCWD,"/dev/urandom",O_RDONLY,00) = 3 (0x3)
fcntl(3,F_GETFD,) = 0 (0x0)
fcntl(3,F_SETFD,FD_CLOEXEC) = 0 (0x0)
Vladimír Čunát
@vcunat
Aug 04 2017 10:13
There should be. I'm getting
open("/dev/srandom", O_RDONLY)          = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY)          = 15
read(15, ..., 256) = 256
close(15)
That is, I just assume that fread in FreeBSD's libc is implemented via read.
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 11:18
hmm tried the custom test as well, with max number of queries, still 0.22 lost entropy
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 12:41
just finished building from rand_uint, but same, but no real change
Vladimír Čunát
@vcunat
Aug 04 2017 12:46
I find it likely that even on FreeBSD it got read in a single go, meaning no change at all. (strace should show that)
The fix concerned the unlikely possibility of the read being "interrupted" for some reason.
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:23
any other ideas? wonder if its worth trying to hardcode a seed and see what happens
Vladimír Čunát
@vcunat
Aug 04 2017 14:25
You can try that - changing to reading from a different path is trivial. I don't know the nature of the generator that we use there. Many would give good results with any seed, assuming it's not known to the attacker.
On the whole, I'm completely out of ideas about why you might be getting so different results than me.
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:26
would it be difficult to print out some sort of debug for a known good seed that I could hardcode?
or could gcc optimization flags have any effect?
wonder what flags you use and with which version of gcc?
Vladimír Čunát
@vcunat
Aug 04 2017 14:27
Hmm, optimization and/or architecture... that's only possible with broken compiler or code containing undefined behavior. Neither seems likely to me.
I run the tests with gcc-5.4.0, CFLAGS -O2 -DNDEBUG + various hardening flags (distro defaults).
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:41
guess i could also try isaac64?
Vladimír Čunát
@vcunat
Aug 04 2017 14:42
The main difference should be that it's designed to return 64-bit random numbers.
(but I haven't looked into details)
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:43
looks like the cost is 18.75 cycles vs 19 cycles, so i guess i should at least try it to see if it returns better results or not
Vladimír Čunát
@vcunat
Aug 04 2017 14:43
Our current usage is perfectly OK with 32-bit ones. (And we also have a large deployment on 32-bit ARMs.)
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:44
yeah. still confused why it would be different on freebsd
Vladimír Čunát
@vcunat
Aug 04 2017 14:45
To be sure, the whole table I was getting:
Query Transaction ID Analysis (worst case)
Max Entropy: 16 Excellent Dir Bias: 1.68% Excellent
Lost Entropy: 0.06 Excellent Stuck Bits: 0 Excellent
"Dir Bias" was varying around 0.5--2% IIRC.
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:47
I rarely see "Good" on lost entropy, and mostly "Moderate"
everything else was excellent
Dir bias 0.78% from last run
Vladimír Čunát
@vcunat
Aug 04 2017 14:48
Your knot-resolver is the only DNS and it's configured to iterate, right?
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 14:48
yep
Unbound was showing similar results as well though. Wonder if it could be something funny from freebsds math.h?
Vladimír Čunát
@vcunat
Aug 04 2017 14:54
isaac uses just bit operations and addition, no "math".
also modulo is used, but it's certainly all integer
Mike Emigh
@nakame_maiku_twitter
Aug 04 2017 15:35
server listens on multiple addresses, but the results are better if only one address is configured on the client (average of 0.12)
Vladimír Čunát
@vcunat
Aug 04 2017 15:36
Weird. We plan to bind to each address individually by default instead of listening on 0.0.0.0, too.