1. 08 Mar, 2018 2 commits
  2. 07 Mar, 2018 2 commits
  3. 06 Mar, 2018 4 commits
  4. 04 Mar, 2018 2 commits
  5. 03 Mar, 2018 3 commits
  6. 01 Mar, 2018 2 commits
  7. 28 Feb, 2018 1 commit
    • David Benjamin's avatar
      Always use adr with __thumb2__. · fa9ab9ee
      David Benjamin authored
      Thumb2 addresses are a bit a mess, depending on whether a label is
      interpreted as a function pointer value (for use with BX and BLX) or as
      a program counter value (for use with PC-relative addressing). Clang's
      integrated assembler mis-assembles this code. See
      https://crbug.com/124610#c54 for details.
      
      Instead, use the ADR pseudo-instruction which has clear semantics and
      should be supported by every assembler that handles the OpenSSL Thumb2
      code. (In other files, the ADR vs SUB conditionals are based on
      __thumb2__ already. For some reason, this one is based on __APPLE__, I'm
      guessing to deal with an older version of clang assembler.)
      
      It's unclear to me which of clang or binutils is "correct" or if this is
      even a well-defined notion beyond "whatever binutils does". But I will
      note that https://github.com/openssl/openssl/pull/4669
      
       suggests binutils
      has also changed behavior around this before.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      Reviewed-by: default avatarRich Salz <rsalz@opens...>
      fa9ab9ee
  8. 26 Feb, 2018 2 commits
    • Dr. Matthias St. Pierre's avatar
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · 5eb9a426
      Dr. Matthias St. Pierre authored
      Fixes #5405, #1381
      
      The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes.
      When processing input in PEM format it can happen in rare cases that
      
      - the trailing PEM marker crosses the boundary of a chunk, and
      - the beginning of the following chunk contains valid base64 encoded data.
      
      This happened in issue #5405, where the PEM marker was split into
      "-----END CER" and "TIFICATE-----" at the end of the first chunk.
      
      The decoding of the first chunk terminated correctly at the '-' character,
      which is treated as an EOF marker, and b64_read() returned. However,
      when called the second time, b64_read() read the next chunk and interpreted
      the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes
      '4c 81 48 08 04 c4'.
      
      This patch restores the assignment of the error code to 'ctx->cont', which
      was deleted accidentally in commit 5562cfac and which prevents b64_read()
      from reading additional data on subsequent calls...
      5eb9a426
    • Andy Polyakov's avatar
      mem_sec.c: relax POSIX requirement. · 4974a6f2
      Andy Polyakov authored
      
      
      Even though mlock(2) was standardized in POSIX.1-2001, vendors did
      implement it prior that point.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5460)
      
      (cherry picked from commit 5839185c)
      4974a6f2
  9. 24 Feb, 2018 1 commit
  10. 23 Feb, 2018 1 commit
  11. 22 Feb, 2018 1 commit
  12. 21 Feb, 2018 3 commits
  13. 19 Feb, 2018 3 commits
  14. 15 Feb, 2018 2 commits
  15. 14 Feb, 2018 1 commit
    • Viktor Dukhovni's avatar
      Avoid fragile aliasing of SHA224/384 update/final · 144724c7
      Viktor Dukhovni authored
      
      
      This is purported to save a few cycles, but makes the code less
      obvious and more brittle, and in fact breaks on platforms where for
      ABI continuity reasons there is a SHA2 implementation in libc, and
      so EVP needs to call those to avoid conflicts.
      
      A sufficiently good optimizer could simply generate the same entry
      points for:
      
              foo(...) { ... }
          and
              bar(...) { return foo(...); }
      
      but, even without that, the different is negligible, with the
      "winner" varying from run to run (openssl speed -evp sha384):
      
          Old:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k
      
          New:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      144724c7
  16. 13 Feb, 2018 4 commits
  17. 12 Feb, 2018 1 commit
  18. 10 Feb, 2018 2 commits
  19. 09 Feb, 2018 2 commits
  20. 08 Feb, 2018 1 commit