Skip to content
  1. Aug 03, 2017
    • Lingmo Zhu's avatar
      Remove the obsolete misleading comment and code related to it. · 15b3fd6f
      Lingmo Zhu authored
      
      
      The comment "The following should not return 1, otherwise, things
      are very strange" is from the very first commit of OpenSSL. The
      really meaning of the comment is if the identical session can be
      found from internal cache after calling get_session_cb but not
      found before calling get_session_cb, it is just strange.
      
      The value 1 was originated from the old doc of SSLeay, reversed
      from the actual return value of SSL_CTX_add_session().
      
      Anyway either return value of SSL_CTX_add_session() should not
      interrupt the session resumption process. So the checking of
      return value of SSL_CTX_add_session() is not necessary.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4014)
      
      (cherry picked from commit e29bb834)
      15b3fd6f
  2. Aug 01, 2017
  3. Jul 31, 2017
  4. Jul 29, 2017
  5. Jul 28, 2017
  6. Jul 27, 2017
  7. Jul 26, 2017
  8. Jul 25, 2017
    • Andy Polyakov's avatar
      x86_64 assembly pack: "optimize" for Knights Landing. · 738a9dd5
      Andy Polyakov authored
      "Optimize" is in quotes because it's rather a "salvage operation"
      for now. Idea is to identify processor capability flags that
      drive Knights Landing to suboptimial code paths and mask them.
      Two flags were identified, XSAVE and ADCX/ADOX. Former affects
      choice of AES-NI code path specific for Silvermont (Knights Landing
      is of Silvermont "ancestry"). And 64-bit ADCX/ADOX instructions are
      effectively mishandled at decode time. In both cases we are looking
      at ~2x improvement.
      
      Hardware used for benchmarking courtesy of Atos, experiments run by
      Romain Dolbeau <romain.dolbeau@atos.net>. Kudos!
      
      This is minimalistic backpoint of 64d92d74
      
      
      
      Thanks to David Benjamin for spotting typo in Knights Landing detection!
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4006)
      738a9dd5
  9. Jul 24, 2017
  10. Jul 23, 2017
  11. Jul 19, 2017
    • Matt Caswell's avatar
      Remove some dead code · 42aebbd5
      Matt Caswell authored
      
      
      The intention of the removed code was to check if the previous operation
      carried. However this does not work. The "mask" value always ends up being
      a constant and is all ones - thus it has no effect. This check is no longer
      required because of the previous commit.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3832)
      
      (cherry picked from commit d5475e31)
      42aebbd5
    • Matt Caswell's avatar
      Fix undefined behaviour in e_aes_cbc_hmac_sha256.c and e_aes_cbc_hmac_sha1.c · 6db7d015
      Matt Caswell authored
      
      
      In TLS mode of operation the padding value "pad" is obtained along with the
      maximum possible padding value "maxpad". If pad > maxpad then the data is
      invalid. However we must continue anyway because this is constant time code.
      
      We calculate the payload length like this:
      
          inp_len = len - (SHA_DIGEST_LENGTH + pad + 1);
      
      However if pad is invalid then inp_len ends up -ve (actually large +ve
      because it is a size_t).
      
      Later we do this:
      
          /* verify HMAC */
          out += inp_len;
          len -= inp_len;
      
      This ends up with "out" pointing before the buffer which is undefined
      behaviour. Next we calculate "p" like this:
      
          unsigned char *p =
              out + len - 1 - maxpad - SHA256_DIGEST_LENGTH;
      
      Because of the "out + len" term the -ve inp_len value is cancelled out
      so "p" points to valid memory (although technically the pointer arithmetic
      is undefined behaviour again).
      
      We only ever then dereference "p" and never "out" directly so there is
      never an invalid read based on the bad pointer - so there is no security
      issue.
      
      This commit fixes the undefined behaviour by ensuring we use maxpad in
      place of pad, if the supplied pad is invalid.
      
      With thanks to Brian Carpenter for reporting this issue.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3832)
      
      (cherry picked from commit 335d0a46)
      6db7d015
  12. Jul 18, 2017
  13. Jul 17, 2017
  14. Jul 14, 2017
  15. Jul 10, 2017
  16. Jul 09, 2017
  17. Jul 07, 2017
  18. Jul 05, 2017