TODO for 5.2 v3

Torbjorn Granlund tg at
Thu Jan 16 15:32:02 UTC 2014

nisse at (Niels Möller) writes:

  Question is, when is it useful for our purposes? First example,
    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,
    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;
      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

  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

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.

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list