1. 23 Jun, 2016 1 commit
    • Mathias Krause's avatar
      crypto: user - re-add size check for CRYPTO_MSG_GETALG · 055ddaac
      Mathias Krause authored
      Commit 9aa867e4 ("crypto: user - Add CRYPTO_MSG_DELRNG")
      accidentally removed the minimum size check for CRYPTO_MSG_GETALG
      netlink messages. This allows userland to send a truncated
      CRYPTO_MSG_GETALG message as short as a netlink header only making
      crypto_report() operate on uninitialized memory by accessing data
      beyond the end of the netlink message.
      Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG
      messages to the crypto_msg_min[] array.
      Fixes: 9aa867e4 ("crypto: user - Add CRYPTO_MSG_DELRNG")
      Cc: stable@vger.kernel.org	# v4.2
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  2. 19 May, 2016 1 commit
    • Arnd Bergmann's avatar
      crypto: public_key: select CRYPTO_AKCIPHER · bad6a185
      Arnd Bergmann authored
      In some rare randconfig builds, we can end up with
      which fails to link because of the reference to crypto_alloc_akcipher:
      crypto/built-in.o: In function `public_key_verify_signature':
      :(.text+0x110e4): undefined reference to `crypto_alloc_akcipher'
      This adds a Kconfig 'select' statement to ensure the dependency
      is always there.
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  3. 11 May, 2016 1 commit
  4. 09 May, 2016 1 commit
  5. 05 May, 2016 3 commits
  6. 15 Apr, 2016 2 commits
  7. 11 Apr, 2016 6 commits
    • David Howells's avatar
      KEYS: Move the point of trust determination to __key_link() · a511e1af
      David Howells authored
      Move the point at which a key is determined to be trustworthy to
      __key_link() so that we use the contents of the keyring being linked in to
      to determine whether the key being linked in is trusted or not.
      What is 'trusted' then becomes a matter of what's in the keyring.
      Currently, the test is done when the key is parsed, but given that at that
      point we can only sensibly refer to the contents of the system trusted
      keyring, we can only use that as the basis for working out the
      trustworthiness of a new key.
      With this change, a trusted keyring is a set of keys that once the
      trusted-only flag is set cannot be added to except by verification through
      one of the contained keys.
      Further, adding a key into a trusted keyring, whilst it might grant
      trustworthiness in the context of that keyring, does not automatically
      grant trustworthiness in the context of a second keyring to which it could
      be secondarily linked.
      To accomplish this, the authentication data associated with the key source
      must now be retained.  For an X.509 cert, this means the contents of the
      AuthorityKeyIdentifier and the signature data.
      If system keyrings are disabled then restrict_link_by_builtin_trusted()
      resolves to restrict_link_reject().  The integrity digital signature code
      still works correctly with this as it was previously using
      KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there
      is no system keyring against which trust can be determined.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Make the system trusted keyring depend on the asymmetric key type · 99716b7c
      David Howells authored
      Make the system trusted keyring depend on the asymmetric key type as
      there's not a lot of point having it if you can't then load asymmetric keys
      onto it.
      This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as
      the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to
      'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.
      Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't
      work as the Kconfig interpreter then wrongly complains about dependency
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Move the trust validation code out to its own file · cfb664ff
      David Howells authored
      Move the X.509 trust validation code out to its own file so that it can be
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Use verify_signature() if we have a struct key * to use · 5f7f5c81
      David Howells authored
      We should call verify_signature() rather than directly calling
      public_key_verify_signature() if we have a struct key to use as we
      shouldn't be poking around in the private data of the key struct as that's
      subtype dependent.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Generalise x509_request_asymmetric_key() · 9eb02989
      David Howells authored
      Generalise x509_request_asymmetric_key().  It doesn't really have any
      dependencies on X.509 features as it uses generalised IDs and the
      public_key structs that contain data extracted from X.509.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c · 983023f2
      David Howells authored
      Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  8. 06 Apr, 2016 9 commits
    • David Howells's avatar
      PKCS#7: Make trust determination dependent on contents of trust keyring · bda850cd
      David Howells authored
      Make the determination of the trustworthiness of a key dependent on whether
      a key that can verify it is present in the supplied ring of trusted keys
      rather than whether or not the verifying key has KEY_FLAG_TRUSTED set.
      verify_pkcs7_signature() will return -ENOKEY if the PKCS#7 message trust
      chain cannot be verified.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Generalise system_verify_data() to provide access to internal content · e68503bd
      David Howells authored
      Generalise system_verify_data() to provide access to internal content
      through a callback.  This allows all the PKCS#7 stuff to be hidden inside
      this function and removed from the PE file parser and the PKCS#7 test key.
      If external content is not required, NULL should be passed as data to the
      function.  If the callback is not required, that can be set to NULL.
      The function is now called verify_pkcs7_signature() to contrast with
      verify_pefile_signature() and the definitions of both have been moved into
      linux/verification.h along with the key_being_used_for enum.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Fix self-signed determination · ad3043fd
      David Howells authored
      There's a bug in the code determining whether a certificate is self-signed
      or not: if they have neither AKID nor SKID then we just assume that the
      cert is self-signed, which may not be true.
      Fix this by checking that the raw subject name matches the raw issuer name
      and that the public key algorithm for the key and signature are both the
      same in addition to requiring that the AKID bits match.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Extract signature digest and make self-signed cert checks earlier · 6c2dc5ae
      David Howells authored
      Extract the signature digest for an X.509 certificate earlier, at the end
      of x509_cert_parse() rather than leaving it to the callers thereof since it
      has to be called anyway.
      Further, immediately after that, check the signature on self-signed
      certificates, also rather in the callers of x509_cert_parse().
      We note in the x509_certificate struct the following bits of information:
       (1) Whether the signature is self-signed (even if we can't check the
           signature due to missing crypto).
       (2) Whether the key held in the certificate needs unsupported crypto to be
           used.  We may get a PKCS#7 message with X.509 certs that we can't make
           use of - we just ignore them and give ENOPKG at the end it we couldn't
           verify anything if at least one of these unusable certs are in the
           chain of trust.
       (3) Whether the signature held in the certificate needs unsupported crypto
           to be checked.  We can still use the key held in this certificate,
           even if we can't check the signature on it - if it is held in the
           system trusted keyring, for instance.  We just can't add it to a ring
           of trusted keys or follow it further up the chain of trust.
      Making these checks earlier allows x509_check_signature() to be removed and
      replaced with direct calls to public_key_verify_signature().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      PKCS#7: Make the signature a pointer rather than embedding it · 566a117a
      David Howells authored
      Point to the public_key_signature struct from the pkcs7_signed_info struct
      rather than embedding it.  This makes the code consistent with the X.509
      signature handling and makes it possible to have a common cleanup function.
      We also save a copy of the digest in the signature without sharing the
      memory with the crypto layer metadata.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Retain the key verification data · 77d0910d
      David Howells authored
      Retain the key verification data (ie. the struct public_key_signature)
      including the digest and the key identifiers.
      Note that this means that we need to take a separate copy of the digest in
      x509_get_sig_params() rather than lumping it in with the crypto layer data.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Add identifier pointers to public_key_signature struct · a022ec02
      David Howells authored
      Add key identifier pointers to public_key_signature struct so that they can
      be used to retain the identifier of the key to be used to verify the
      signature in both PKCS#7 and X.509.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      KEYS: Allow authentication data to be stored in an asymmetric key · 3b764563
      David Howells authored
      Allow authentication data to be stored in an asymmetric key in the 4th
      element of the key payload and provide a way for it to be destroyed.
      For the public key subtype, this will be a public_key_signature struct.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    • David Howells's avatar
      X.509: Whitespace cleanup · 864e7a81
      David Howells authored
      Clean up some whitespace.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  9. 05 Apr, 2016 3 commits
  10. 23 Mar, 2016 1 commit
    • Nicolai Stange's avatar
      PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument · e5435891
      Nicolai Stange authored
      Despite what the DocBook comment to pkcs7_validate_trust() says, the
      *_trusted argument is never set to false.
      pkcs7_validate_trust() only positively sets *_trusted upon encountering
      a trusted PKCS#7 SignedInfo block.
      This is quite unfortunate since its callers, system_verify_data() for
      example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust.
      Indeed, UBSAN splats when attempting to load the uninitialized local
      variable 'trusted' from system_verify_data() in pkcs7_validate_trust():
        UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14
        load of value 82 is not a valid value for type '_Bool'
        Call Trace:
          [<ffffffff818c4d35>] dump_stack+0xbc/0x117
          [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
          [<ffffffff8194113b>] ubsan_epilogue+0xd/0x4e
          [<ffffffff819419fa>] __ubsan_handle_load_invalid_value+0x111/0x158
          [<ffffffff819418e9>] ? val_to_string.constprop.12+0xcf/0xcf
          [<ffffffff818334a4>] ? x509_request_asymmetric_key+0x114/0x370
          [<ffffffff814b83f0>] ? kfree+0x220/0x370
          [<ffffffff818312c2>] ? public_key_verify_signature_2+0x32/0x50
          [<ffffffff81835e04>] pkcs7_validate_trust+0x524/0x5f0
          [<ffffffff813c391a>] system_verify_data+0xca/0x170
          [<ffffffff813c3850>] ? top_trace_array+0x9b/0x9b
          [<ffffffff81510b29>] ? __vfs_read+0x279/0x3d0
          [<ffffffff8129372f>] mod_verify_sig+0x1ff/0x290
      The implication is that pkcs7_validate_trust() effectively grants trust
      when it really shouldn't have.
      Fix this by explicitly setting *_trusted to false at the very beginning
      of pkcs7_validate_trust().
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  11. 17 Mar, 2016 1 commit
    • Joonsoo Kim's avatar
      mm/page_ref: add tracepoint to track down page reference manipulation · 95813b8f
      Joonsoo Kim authored
      CMA allocation should be guaranteed to succeed by definition, but,
      unfortunately, it would be failed sometimes.  It is hard to track down
      the problem, because it is related to page reference manipulation and we
      don't have any facility to analyze it.
      This patch adds tracepoints to track down page reference manipulation.
      With it, we can find exact reason of failure and can fix the problem.
      Following is an example of tracepoint output.  (note: this example is
      stale version that printing flags as the number.  Recent version will
      print it as human readable string.)
      <...>-9018  [004]    92.678375: page_ref_set:         pfn=0x17ac9 flags=0x0 count=1 mapcount=0 mapping=(nil) mt=4 val=1
      <...>-9018  [004]    92.678378: kernel_stack:
       => get_page_from_freelist (ffffffff81176659)
       => __alloc_pages_nodemask (ffffffff81176d22)
       => alloc_pages_vma (ffffffff811bf675)
       => handle_mm_fault (ffffffff8119e693)
       => __do_page_fault (ffffffff810631ea)
       => trace_do_page_fault (ffffffff81063543)
       => do_async_page_fault (ffffffff8105c40a)
       => async_page_fault (ffffffff817581d8)
      <...>-9018  [004]    92.678379: page_ref_mod:         pfn=0x17ac9 flags=0x40048 count=2 mapcount=1 mapping=0xffff880015a78dc1 mt=4 val=1
      <...>-9131  [001]    93.174468: test_pages_isolated:  start_pfn=0x17800 end_pfn=0x17c00 fin_pfn=0x17ac9 ret=fail
      <...>-9018  [004]    93.174843: page_ref_mod_and_test: pfn=0x17ac9 flags=0x40068 count=0 mapcount=0 mapping=0xffff880015a78dc1 mt=4 val=-1 ret=1
       => release_pages (ffffffff8117c9e4)
       => free_pages_and_swap_cache (ffffffff811b0697)
       => tlb_flush_mmu_free (ffffffff81199616)
       => tlb_finish_mmu (ffffffff8119a62c)
       => exit_mmap (ffffffff811a53f7)
       => mmput (ffffffff81073f47)
       => do_exit (ffffffff810794e9)
       => do_group_exit (ffffffff81079def)
       => SyS_exit_group (ffffffff81079e74)
       => entry_SYSCALL_64_fastpath (ffffffff817560b6)
      This output shows that problem comes from exit path.  In exit path, to
      improve performance, pages are not freed immediately.  They are gathered
      and processed by batch.  During this process, migration cannot be
      possible and CMA allocation is failed.  This problem is hard to find
      without this page reference tracepoint facility.
      Enabling this feature bloat kernel text 30 KB in my configuration.
         text    data     bss     dec     hex filename
      12127327        2243616 1507328 15878271         f2487f vmlinux_disabled
      12157208        2258880 1507328 15923416         f2f8d8 vmlinux_enabled
      Note that, due to header file dependency problem between mm.h and
      tracepoint.h, this feature has to open code the static key functions for
      tracepoints.  Proposed by Steven Rostedt in following link.
      [arnd@arndb.de: crypto/async_pq: use __free_page() instead of put_page()]
      [iamjoonsoo.kim@lge.com: fix build failure for xtensa]
      [akpm@linux-foundation.org: tweak Kconfig text, per Vlastimil]
      Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  12. 03 Mar, 2016 3 commits
  13. 29 Feb, 2016 4 commits
    • David Howells's avatar
      X.509: Handle midnight alternative notation in GeneralizedTime · 7650cb80
      David Howells authored
      The ASN.1 GeneralizedTime object carries an ISO 8601 format date and time.
      The time is permitted to show midnight as 00:00 or 24:00 (the latter being
      equivalent of 00:00 of the following day).
      The permitted value is checked in x509_decode_time() but the actual
      handling is left to mktime64().
      Without this patch, certain X.509 certificates will be rejected and could
      lead to an unbootable kernel.
      Note that with this patch we also permit any 24:mm:ss time and extend this
      to UTCTime, which whilst not strictly correct don't permit much leeway in
      fiddling date strings.
      Reported-by: default avatarRudolf Polzer <rpolzer@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      cc: David Woodhouse <David.Woodhouse@intel.com>
      cc: John Stultz <john.stultz@linaro.org>
    • David Howells's avatar
      X.509: Support leap seconds · da02559c
      David Howells authored
      The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601
      [X.680 46.3] and this apparently supports leap seconds (ie. the seconds
      field is 60).  It's not entirely clear that ASN.1 expects it, but we can
      relax the seconds check slightly for GeneralizedTime.
      This results in us passing a time with sec as 60 to mktime64(), which
      handles it as being a duplicate of the 0th second of the next minute.
      We can't really do otherwise without giving the kernel much greater
      knowledge of where all the leap seconds are.  Unfortunately, this would
      require change the mapping of the kernel's current-time-in-seconds.
      UTCTime, however, only supports a seconds value in the range 00-59, but for
      the sake of simplicity allow this with UTCTime also.
      Without this patch, certain X.509 certificates will be rejected,
      potentially making a kernel unbootable.
      Reported-by: default avatarRudolf Polzer <rpolzer@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      cc: David Woodhouse <David.Woodhouse@intel.com>
      cc: John Stultz <john.stultz@linaro.org>
    • David Howells's avatar
      X.509: Fix leap year handling again · ac4cbedf
      David Howells authored
      There are still a couple of minor issues in the X.509 leap year handling:
       (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
           determining whether the year is a leap year or not, I divided the year
           by 100 after doing the modulus-by-100, thereby letting the compiler do
           one instruction for both, and then did a modulus-by-4.
           Unfortunately, I then passed the now-modified year value to mktime64()
           to construct a time value.
           Since this isn't a fast path and since mktime64() does a bunch of
           divisions, just condense down to "% 400".  It's also easier to read.
       (2) The default month length for any February where the year doesn't
           divide by four exactly is obtained from the month_length[] array where
           the value is 29, not 28.
           This is fixed by altering the table.
      Reported-by: default avatarRudolf Polzer <rpolzer@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      cc: stable@vger.kernel.org
    • Colin Ian King's avatar
      PKCS#7: fix unitialized boolean 'want' · 06aae592
      Colin Ian King authored
      The boolean want is not initialized and hence garbage. The default should
      be false (later it is only set to true on tne sinfo->authattrs check).
      Found with static analysis using CoverityScan
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  14. 27 Feb, 2016 1 commit
  15. 16 Feb, 2016 2 commits
  16. 10 Feb, 2016 1 commit