TODO for 5.2 v3

[Torbjorn Granlund]

nisse at 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