Skip to content
  1. Mar 10, 2018
  2. Mar 09, 2018
  3. Mar 08, 2018
  4. Mar 07, 2018
  5. Mar 06, 2018
  6. Mar 04, 2018
  7. Mar 03, 2018
  8. Mar 01, 2018
  9. Feb 28, 2018
    • 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@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5431)
      
      (cherry picked from commit 8a5d8bc4)
      fa9ab9ee
  10. Feb 26, 2018
    • 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.
      
      This issue was observed and reported by Annie Yousar.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5422)
      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
  11. Feb 24, 2018
  12. Feb 23, 2018
  13. Feb 22, 2018
  14. Feb 21, 2018
  15. Feb 19, 2018
  16. Feb 15, 2018
  17. Feb 14, 2018
    • 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
  18. Feb 13, 2018
  19. Feb 12, 2018
  20. Feb 10, 2018