ni...@lysator.liu.se (Niels Möller) writes:
Question is, when is it useful for our purposes? First example,
mpn_sec_add_1:
mp_limb_t
mpn_sec_add_1 (mp_limb_t *rp, mp_limb_t *ap, mp_size_t n, mp_limb_t b,
mp_ptr scratch)
{
scratch[0] = b;
MPN_ZERO (scratch + 1, n-1);
return mpn_add_n (rp, ap, scratch, n);
}
volatile probably makes no difference here, as far as I see (except
possibly if there's some global optimization which inlines mpn_add_n).
I suppose such a hypothetical inline could mess up things, since
mpn_add_n is not required to treat its reads and writes as 'volatile'; A
clever ompiler could analyse the state of {scratch,n} and replace
mpn_add_n by mpn_add_1...
But maybe we should still declare some or all of the parameters (rp, ap,
scratch) as pointing to volatile data?
I don't see tat making a difference.
Second example,
void
mpn_cnd_swap (mp_limb_t cnd,
mp_limb_t *ap, mp_limb_t *bp, mp_size_t n)
{
mp_limb_t mask = - (mp_limb_t) (cnd != 0);
mp_size_t i;
for (i = 0; i < n; i++)
{
mp_limb_t a, b, t;
a = ap[i];
b = bp[i];
t = (a ^ b) & mask;
ap[i] = a ^ t;
bp[i] = b ^ t;
}
}
Here a compiler might be tempted to do an initial branch on cnd != 0,
and skip the loop if cnd is false. Using volatile for ap and bp gives it
less reason to do so, but I guess even with volatile it may still
generate code equivalent to
if (cnd)
for (i = 0; i < n; i++)
{
mp_limb_t a, b, t;
a = ap[i];
b = bp[i];
ap[i] = b;
bp[i] = a;
}
else
for (i = 0; i < n; i++)
{
mp_limb_t a, b, t;
a = ap[i];
b = bp[i];
ap[i] = a;
bp[i] = b;
}
which leaks through the cache.
Yes, it leaks through the branch prediction state and the instruction
cache.
So is it useful or not to volatile-declare ap and bp here?
I think so, even if Marc's hypothetical scenario is possible.
In practice, the only real problem is condition-to-mask. We could solve
that with trivial asm functions (but then, how to we handle
--disable-assembly?).
We might want to bring these issues up with the gcc team. While
side-channel problems might not be generally appreciated among compiler
hackers, some of them surely will have some understanding of this area.
Torbjörn
Please encrypt, key id 0xC8601622
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
