-
Notifications
You must be signed in to change notification settings - Fork 569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add iterator debugging to CI #4413
Conversation
Can't repro the CI failures locally Not TPM2, the fuzzers job is also failing and that doesn't run the TPM2 tests. Seems to be |
a9f7357
to
73ef2ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Thanks for picking this up. :)
if(rng->next_byte() & 1) { | ||
a.set_bit(i); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Off topic: should we introduce something like rng->next_bit() -> CT::Choice
? Not sure whether that would be useful in production code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe? I can't think of cases currently where we predicate on a single random bit (vs say the even-y bit of a EC point). Somewhere in the PQ algos perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. They all just pull a seed and then sample from KDFs or XOFs. I didn't find something with an ad-hoc search either.
For some of those samplings, we have to pull a number of bits that isn't aligned by 8 from the XOF (without losing the other bits). For instance, this is generating uint16_ts that are comprised of 12 bits pulled from the XOF. This required some generator adapters to pull off.
botan/src/lib/pubkey/kyber/kyber_common/kyber_algos.cpp
Lines 94 to 97 in bd045b1
const auto [d1, d2] = bounded_xof.next<3>([&](const auto bytes) { | |
const auto x = load_le3(bytes); | |
return std::pair{lowerthan_q(x & 0x0FFF), lowerthan_q(x >> 12)}; | |
}); |
But introducing a bit-oriented API just for this? Not really, I think.
The iterator checks failed when we attempted to use first to extract ideal_granularity bytes out of dummy_buffer, but on testing it failed exactly when ideal_granularity was 256 bytes, the same size as dummy_buffer itself. Increase the size and add an assert that the buffer is large enough.
This is not helpful in any case, and I ran into some very confusing situations attempting to replicate iterator errors on Ubuntu 24.04 apparently caused by ccache not noticing that the inputs had changed.
Even without iterator checks, running the tests with 8192 bits takes 35 seconds on a reasonably fast machine, and it takes over 5 minutes with GCC iterator checks enabled. While there also randomize the test input
73ef2ef
to
082bdea
Compare
See #3737 #3840