1. 11 Apr, 2016 1 commit
    • 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>
  2. 06 Apr, 2016 2 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>
  3. 03 Mar, 2016 1 commit
  4. 01 Mar, 2016 1 commit
  5. 21 Oct, 2015 1 commit
    • David Howells's avatar
      KEYS: Merge the type-specific data with the payload data · 146aa8b1
      David Howells authored
      Merge the type-specific data with the payload data into one four-word chunk
      as it seems pointless to keep them separate.
      Use user_key_payload() for accessing the payloads of overloaded
      user-defined keys.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: linux-cifs@vger.kernel.org
      cc: ecryptfs@vger.kernel.org
      cc: linux-ext4@vger.kernel.org
      cc: linux-f2fs-devel@lists.sourceforge.net
      cc: linux-nfs@vger.kernel.org
      cc: ceph-devel@vger.kernel.org
      cc: linux-ima-devel@lists.sourceforge.net
  6. 12 Aug, 2015 1 commit
    • David Howells's avatar
      PKCS#7: Appropriately restrict authenticated attributes and content type · 99db4435
      David Howells authored
      A PKCS#7 or CMS message can have per-signature authenticated attributes
      that are digested as a lump and signed by the authorising key for that
      signature.  If such attributes exist, the content digest isn't itself
      signed, but rather it is included in a special authattr which then
      contributes to the signature.
      Further, we already require the master message content type to be
      pkcs7_signedData - but there's also a separate content type for the data
      itself within the SignedData object and this must be repeated inside the
      authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
      We should really validate the authattrs if they exist or forbid them
      entirely as appropriate.  To this end:
       (1) Alter the PKCS#7 parser to reject any message that has more than one
           signature where at least one signature has authattrs and at least one
           that does not.
       (2) Validate authattrs if they are present and strongly restrict them.
           Only the following authattrs are permitted and all others are
           (a) contentType.  This is checked to be an OID that matches the
           	 content type in the SignedData object.
           (b) messageDigest.  This must match the crypto digest of the data.
           (c) signingTime.  If present, we check that this is a valid, parseable
           	 UTCTime or GeneralTime and that the date it encodes fits within
           	 the validity window of the matching X.509 cert.
           (d) S/MIME capabilities.  We don't check the contents.
           (e) Authenticode SP Opus Info.  We don't check the contents.
           (f) Authenticode Statement Type.  We don't check the contents.
           The message is rejected if (a) or (b) are missing.  If the message is
           an Authenticode type, the message is rejected if (e) is missing; if
           not Authenticode, the message is rejected if (d) - (f) are present.
           The S/MIME capabilities authattr (d) unfortunately has to be allowed
           to support kernels already signed by the pesign program.  This only
           affects kexec.  sign-file suppresses them (CMS_NOSMIMECAP).
           The message is also rejected if an authattr is given more than once or
           if it contains more than one element in its set of values.
       (3) Add a parameter to pkcs7_verify() to select one of the following
           restrictions and pass in the appropriate option from the callers:
      	 This requires that the SignedData content type be pkcs7-data and
      	 forbids authattrs.  sign-file sets CMS_NOATTR.  We could be more
      	 flexible and permit authattrs optionally, but only permit minimal
      	 This requires that the SignedData content type be pkcs7-data and
      	 requires authattrs.  In future, this will require an attribute
      	 holding the target firmware name in addition to the minimal set.
      	 This requires that the SignedData content type be pkcs7-data but
      	 allows either no authattrs or only permits the minimal set.
      	 This only supports the Authenticode SPC_INDIRECT_DATA content type
      	 and requires at least an SpcSpOpusInfo authattr in addition to the
      	 minimal set.  It also permits an SPC_STATEMENT_TYPE authattr (and
      	 an S/MIME capabilities authattr because the pesign program doesn't
      	 remove these).
      	 These are invalid in this context but are included for later use
      	 when limiting the use of X.509 certs.
       (4) The pkcs7_test key type is given a module parameter to select between
           the above options for testing purposes.  For example:
      	echo 1 >/sys/module/pkcs7_test_key/parameters/usage
      	keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
           will attempt to check the signature on stuff.pkcs7 as if it contains a
           firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
      Suggested-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  7. 07 Aug, 2015 2 commits
    • David Howells's avatar
      MODSIGN: Extract the blob PKCS#7 signature verifier from module signing · 091f6e26
      David Howells authored
      Extract the function that drives the PKCS#7 signature verification given a
      data blob and a PKCS#7 blob out from the module signing code and lump it with
      the system keyring code as it's generic.  This makes it independent of module
      config options and opens it to use by the firmware loader.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Seth Forshee <seth.forshee@canonical.com>
      Cc: Kyle McMartin <kyle@kernel.org>
    • David Howells's avatar
      MODSIGN: Use PKCS#7 messages as module signatures · 3f1e1bea
      David Howells authored
      Move to using PKCS#7 messages as module signatures because:
       (1) We have to be able to support the use of X.509 certificates that don't
           have a subjKeyId set.  We're currently relying on this to look up the
           X.509 certificate in the trusted keyring list.
       (2) PKCS#7 message signed information blocks have a field that supplies the
           data required to match with the X.509 certificate that signed it.
       (3) The PKCS#7 certificate carries fields that specify the digest algorithm
           used to generate the signature in a standardised way and the X.509
           certificates specify the public key algorithm in a standardised way - so
           we don't need our own methods of specifying these.
       (4) We now have PKCS#7 message support in the kernel for signed kexec purposes
           and we can make use of this.
      To make this work, the old sign-file script has been replaced with a program
      that needs compiling in a previous patch.  The rules to build it are added
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarVivek Goyal <vgoyal@redhat.com>
  8. 25 Oct, 2013 1 commit
  9. 25 Sep, 2013 2 commits
  10. 05 Dec, 2012 1 commit
  11. 22 Oct, 2012 1 commit
  12. 20 Oct, 2012 1 commit
    • David Howells's avatar
      MODSIGN: Move the magic string to the end of a module and eliminate the search · caabe240
      David Howells authored
      Emit the magic string that indicates a module has a signature after the
      signature data instead of before it.  This allows module_sig_check() to
      be made simpler and faster by the elimination of the search for the
      magic string.  Instead we just need to do a single memcmp().
      This works because at the end of the signature data there is the
      fixed-length signature information block.  This block then falls
      immediately prior to the magic number.
      From the contents of the information block, it is trivial to calculate
      the size of the signature data and thus the size of the actual module
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  13. 10 Oct, 2012 2 commits
    • David Howells's avatar
      MODSIGN: Implement module signature checking · 48ba2462
      David Howells authored
      Check the signature on the module against the keys compiled into the kernel or
      available in a hardware key store.
      Currently, only RSA keys are supported - though that's easy enough to change,
      and the signature is expected to contain raw components (so not a PGP or
      PKCS#7 formatted blob).
      The signature blob is expected to consist of the following pieces in order:
       (1) The binary identifier for the key.  This is expected to match the
           SubjectKeyIdentifier from an X.509 certificate.  Only X.509 type
           identifiers are currently supported.
       (2) The signature data, consisting of a series of MPIs in which each is in
           the format of a 2-byte BE word sizes followed by the content data.
       (3) A 12 byte information block of the form:
      	struct module_signature {
      		enum pkey_algo		algo : 8;
      		enum pkey_hash_algo	hash : 8;
      		enum pkey_id_type	id_type : 8;
      		u8			__pad;
      		__be32			id_length;
      		__be32			sig_length;
           The three enums are defined in crypto/public_key.h.
           'algo' contains the public-key algorithm identifier (0->DSA, 1->RSA).
           'hash' contains the digest algorithm identifier (0->MD4, 1->MD5, 2->SHA1,
           'id_type' contains the public-key identifier type (0->PGP, 1->X.509).
           '__pad' should be 0.
           'id_length' should contain in the binary identifier length in BE form.
           'sig_length' should contain in the signature data length in BE form.
           The lengths are in BE order rather than CPU order to make dealing with
           cross-compilation easier.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (minor Kconfig fix)
    • Rusty Russell's avatar
      module: signature checking hook · 106a4ee2
      Rusty Russell authored
      We do a very simple search for a particular string appended to the module
      (which is cache-hot and about to be SHA'd anyway).  There's both a config
      option and a boot parameter which control whether we accept or fail with
      unsigned modules and modules that are signed with an unknown key.
      If module signing is enabled, the kernel will be tainted if a module is
      loaded that is unsigned or has a signature for which we don't have the
      (Useful feedback and tweaks by David Howells <dhowells@redhat.com>)
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  14. 08 Oct, 2012 1 commit
    • David Howells's avatar
      KEYS: Implement asymmetric key type · 964f3b3b
      David Howells authored
      Create a key type that can be used to represent an asymmetric key type for use
      in appropriate cryptographic operations, such as encryption, decryption,
      signature generation and signature verification.
      The key type is "asymmetric" and can provide access to a variety of
      cryptographic algorithms.
      Possibly, this would be better as "public_key" - but that has the disadvantage
      that "public key" is an overloaded term.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  15. 21 Dec, 2011 1 commit
    • Peter Zijlstra's avatar
      perf, arch: Rework perf_event_index() · 35edc2a5
      Peter Zijlstra authored
      Put the logic to compute the event index into a per pmu method. This
      is required because the x86 rules are weird and wonderful and don't
      match the capabilities of the current scheme.
      AFAIK only powerpc actually has a usable userspace read of the PMCs
      but I'm not at all sure anybody actually used that.
      ARM is restored to the default since it currently does not support
      userspace access at all. And all software events are provided with a
      method that reports their index as 0 (disabled).
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Arun Sharma <asharma@fb.com>
      Link: http://lkml.kernel.org/n/tip-dfydxodki16lylkt3gl2j7cw@git.kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
  16. 21 Sep, 2009 1 commit
    • Ingo Molnar's avatar
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar authored
      Bye-bye Performance Counters, welcome Performance Events!
      In the past few months the perfcounters subsystem has grown out its
      initial role of counting hardware events, and has become (and is
      becoming) a much broader generic event enumeration, reporting, logging,
      monitoring, analysis facility.
      Naming its core object 'perf_counter' and naming the subsystem
      'perfcounters' has become more and more of a misnomer. With pending
      code like hw-breakpoints support the 'counter' name is less and
      less appropriate.
      All in one, we've decided to rename the subsystem to 'performance
      events' and to propagate this rename through all fields, variables
      and API names. (in an ABI compatible fashion)
      The word 'event' is also a bit shorter than 'counter' - which makes
      it slightly more convenient to write/handle as well.
      Thanks goes to Stephane Eranian who first observed this misnomer and
      suggested a rename.
      User-space tooling and ABI compatibility is not affected - this patch
      should be function-invariant. (Also, defconfigs were not touched to
      keep the size down.)
      This patch has been generated via the following script:
        FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')
        sed -i \
          -e 's/PERF_EVENT_/PERF_RECORD_/g' \
          -e 's/PERF_COUNTER/PERF_EVENT/g' \
          -e 's/perf_counter/perf_event/g' \
          -e 's/nb_counters/nb_events/g' \
          -e 's/swcounter/swevent/g' \
          -e 's/tpcounter_event/tp_event/g' \
        for N in $(find . -name perf_counter.[ch]); do
          M=$(echo $N | sed 's/perf_counter/perf_event/g')
          mv $N $M
        FILES=$(find . -name perf_event.*)
        sed -i \
          -e 's/COUNTER_MASK/REG_MASK/g' \
          -e 's/COUNTER/EVENT/g' \
          -e 's/\<event\>/event_id/g' \
          -e 's/counter/event/g' \
          -e 's/Counter/Event/g' \
      ... to keep it as correct as possible. This script can also be
      used by anyone who has pending perfcounters patches - it converts
      a Linux kernel tree over to the new naming. We tried to time this
      change to the point in time where the amount of pending patches
      is the smallest: the end of the merge window.
      Namespace clashes were fixed up in a preparatory patch - and some
      stylistic fallout will be fixed up in a subsequent patch.
      ( NOTE: 'counters' are still the proper terminology when we deal
        with hardware registers - and these sed scripts are a bit
        over-eager in renaming them. I've undone some of that, but
        in case there's something left where 'counter' would be
        better than 'event' we can undo that on an individual basis
        instead of touching an otherwise nicely automated patch. )
      Suggested-by: default avatarStephane Eranian <eranian@google.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarPaul Mackerras <paulus@samba.org>
      Reviewed-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux-arch@vger.kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  17. 02 Jul, 2009 1 commit
  18. 08 Feb, 2008 2 commits