bn/asm/*-mont.pl: harmonize with BN_from_montgomery_word.#6141
bn/asm/*-mont.pl: harmonize with BN_from_montgomery_word.#6141dot-asm wants to merge 1 commit intoopenssl:masterfrom
Conversation
Montgomery multiplication post-conditions in some of code paths is formally non-constant time. Cache access pattern is result-neutral, but a little bit asymmetric, which might produce a signal [on processor can reorder load and stores at run-time].
dot-asm
added
branch: master
|
BTW! This is unrelated to this merge request, but test_rand hung on qemu-alpha for me. Question is therefore if it's qemu deficiency or would it hang even on hardware? So if anybody has Alpha hardware, it would be nice to hear about it... |
|
The hang appears to be multi-threading deadlock [naturally in multi-threading test in drbgtest]. It still might be qemu-specific problem, but it also might happen that qemu-alpha is slow in an unfortunate way and triggers some subtle timing problem. Which can mean that it can be triggered under some other circumstances. After all, qemu-user simply passes system calls to native kernel... |
|
If I drop amount of threads and reduce time, test does pass occasionally. I mean it doesn't actually go straight to deadlock, but makes some progress, then gets stuck [in futex]. Once again, this is totally unrelated to this request. Request by itself is ready to roll... |
|
Did the old code also fail on qemu-alpha, or is this a new failure? I suppose we could live with new regressions on Alpha, for closing the side-channel on all popular platforms. But maybe it's better to remove the alpha code from this PR? |
|
It's drbgtest that hangs, and alpha-mont.pl is not involved there, at all. It does mean that it hangs even without suggested modification. Yes, I did check. Once again, hang in test_rand is actually unrelated to this request. The fact that it surfaced now is purely because I don't exercise alpha build that often. But I'm a bit reluctant to claim it as [separate] problem with drbg, because it still might be qemu-specific... |
|
As it turns out drbgtest does work with newer qemu-alpha, newer than one I have on my desktop. Formally speaking it's not actually conclusive, because newer qemu might be faster [or slower] than one I have, but it would be appropriate to say that it's much more likely in fact a qemu-specific problem. Once again, "it" is actually unrelated to the code modifications in this request. |
|
Glad to know it's unrelated. I approve. |
richsalz
added
the
approval: done
Montgomery multiplication post-conditions in some of code paths were formally non-constant time. Cache access pattern was result-neutral, but a little bit asymmetric, which might have produced a signal [if processor reordered load and stores at run-time]. Reviewed-by: Rich Salz <[email protected]> (Merged from #6141)
Montgomery multiplication post-conditions in some of code paths were formally non-constant time. Cache access pattern was result-neutral, but a little bit asymmetric, which might have produced a signal [if processor reordered load and stores at run-time]. Reviewed-by: Rich Salz <[email protected]> (Merged from openssl#6141) (cherry picked from commit 774ff8f)
|
It didn't cherry-pick, so there is #6163, while this one is merged and closing... |
2 participants
Montgomery multiplication post-conditions in some of code paths is
formally non-constant time. Cache access pattern is result-neutral,
but a little bit asymmetric, which might produce a signal [on
processor can reorder load and stores at run-time].