1. 10 Oct, 2012 13 commits
    • David Howells's avatar
      MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checking · a5752d11
      David Howells authored
      The current choice of lifetime for the autogenerated X.509 of 100 years,
      putting the validTo date in 2112, causes problems on 32-bit systems where a
      32-bit time_t wraps in 2106.  64-bit x86_64 systems seem to be unaffected.
      
      This can result in something like:
      
      	Loading module verification certificates
      	X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired
      	MODSIGN: Problem loading in-kernel X.509 certificate (-127)
      
      Or:
      
      	X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 is not yet valid
      	MODSIGN: Problem loading in-kernel X.509 certificate (-129)
      
      Instead of turning the dates into time_t values and comparing, turn the system
      clock and the ASN.1 dates into tm structs and compare those piecemeal instead.
      Reported-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      a5752d11
    • Rusty Russell's avatar
      MODSIGN: Make mrproper should remove generated files. · d5b71936
      Rusty Russell authored
      It doesn't, because the clean targets don't include kernel/Makefile, and
      because two files were missing from the list.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      d5b71936
    • David Howells's avatar
      MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certs · e7d113bc
      David Howells authored
      Place an indication that the certificate should use utf8 strings into the
      x509.genkey template generated by kernel/Makefile.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      e7d113bc
    • David Howells's avatar
      MODSIGN: Use the same digest for the autogen key sig as for the module sig · 5e8cb1e4
      David Howells authored
      Use the same digest type for the autogenerated key signature as for the module
      signature so that the hash algorithm is guaranteed to be present in the kernel.
      
      Without this, the X.509 certificate loader may reject the X.509 certificate so
      generated because it was self-signed and the signature will be checked against
      itself - but this won't work if the digest algorithm must be loaded as a
      module.
      
      The symptom is that the key fails to load with the following message emitted
      into the kernel log:
      
      	MODSIGN: Problem loading in-kernel X.509 certificate (-65)
      
      the error in brackets being -ENOPKG.  What you should see is something like:
      
      	MODSIGN: Loaded cert 'Magarathea: Glacier signing key: 9588321144239a119d3406d4c4cf1fbae1836fa0'
      
      Note that this doesn't apply to certificates that are not self-signed as we
      don't check those currently as they require the parent CA certificate to be
      available.
      Reported-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>
      5e8cb1e4
    • David Howells's avatar
      MODSIGN: Sign modules during the build process · 80d65e58
      David Howells authored
      If CONFIG_MODULE_SIG is set, then this patch will cause all modules files to
      to have signatures added.  The following steps will occur:
      
       (1) The module will be linked to foo.ko.unsigned instead of foo.ko
      
       (2) The module will be stripped using both "strip -x -g" and "eu-strip" to
           ensure minimal size for inclusion in an initramfs.
      
       (3) The signature will be generated on the stripped module.
      
       (4) The signature will be appended to the module, along with some information
           about the signature and a magic string that indicates the presence of the
           signature.
      
      Step (3) requires private and public keys to be available.  By default these
      are expected to be found in files:
      
      	signing_key.priv
      	signing_key.x509
      
      in the base directory of the build.  The first is the private key in PEM form
      and the second is the X.509 certificate in DER form as can be generated from
      openssl:
      
      	openssl req \
      		-new -x509 -outform PEM -out signing_key.x509 \
      		-keyout signing_key.priv -nodes \
      		-subj "/CN=H2G2/O=Magrathea/CN=Slartibartfast"
      
      If the secret key is not found then signing will be skipped and the unsigned
      module from (1) will just be copied to foo.ko.
      
      If signing occurs, lines like the following will be seen:
      
      	LD [M]  fs/foo/foo.ko.unsigned
      	STRIP [M] fs/foo/foo.ko.stripped
      	SIGN [M] fs/foo/foo.ko
      
      will appear in the build log.  If the signature step will be skipped and the
      following will be seen:
      
      	LD [M]  fs/foo/foo.ko.unsigned
      	STRIP [M] fs/foo/foo.ko.stripped
      	NO SIGN [M] fs/foo/foo.ko
      
      NOTE!  After the signature step, the signed module _must_not_ be passed through
      strip.  The unstripped, unsigned module is still available at the name on the
      LD [M] line.  This restriction may affect packaging tools (such as rpmbuild)
      and initramfs composition tools.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      80d65e58
    • David Howells's avatar
      MODSIGN: Provide a script for generating a key ID from an X.509 cert · 85ecac79
      David Howells authored
      Provide a script to parse an X.509 certificate and certain pieces of
      information from it in order to generate a key identifier to be included within
      a module signature.
      
      The script takes the Subject Name and extracts (if present) the
      organizationName (O), the commonName (CN) and the emailAddress and fabricates
      the signer's name from them:
      
       (1) If both O and CN exist, then the name will be "O: CN", unless:
      
           (a) CN is prefixed by O, in which case only CN is used.
      
           (b) CN and O share at least the first 7 characters, in which case only CN
           	 is used.
      
       (2) Otherwise, CN is used if present.
      
       (3) Otherwise, O is used if present.
      
       (4) Otherwise the emailAddress is used, if present.
      
       (5) Otherwise a blank name is used.
      
      The script emits a binary encoded identifier in the following form:
      
       - 2 BE bytes indicating the length of the signer's name.
      
       - 2 BE bytes indicating the length of the subject key identifier.
      
       - The characters of the signer's name.
      
       - The bytes of the subject key identifier.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      85ecac79
    • 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,
            etc.).
      
           '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)
      48ba2462
    • David Howells's avatar
      MODSIGN: Provide module signing public keys to the kernel · 631cc66e
      David Howells authored
      Include a PGP keyring containing the public keys required to perform module
      verification in the kernel image during build and create a special keyring
      during boot which is then populated with keys of crypto type holding the public
      keys found in the PGP keyring.
      
      These can be seen by root:
      
      [root@andromeda ~]# cat /proc/keys
      07ad4ee0 I-----     1 perm 3f010000     0     0 crypto    modsign.0: RSA 87b9b3bd []
      15c7f8c3 I-----     1 perm 1f030000     0     0 keyring   .module_sign: 1/4
      ...
      
      It is probably worth permitting root to invalidate these keys, resulting in
      their removal and preventing further modules from being loaded with that key.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      631cc66e
    • David Howells's avatar
      MODSIGN: Automatically generate module signing keys if missing · d441108c
      David Howells authored
      Automatically generate keys for module signing if they're absent so that
      allyesconfig doesn't break.  The builder should consider generating their own
      key and certificate, however, so that the keys are appropriately named.
      
      The private key for the module signer should be placed in signing_key.priv
      (unencrypted!) and the public key in an X.509 certificate as signing_key.x509.
      
      If a transient key is desired for signing the modules, a config file for
      'openssl req' can be placed in x509.genkey, looking something like the
      following:
      
      	[ req ]
      	default_bits = 4096
      	distinguished_name = req_distinguished_name
      	prompt = no
      	x509_extensions = myexts
      
      	[ req_distinguished_name ]
      	O = Magarathea
      	CN = Glacier signing key
      	emailAddress = slartibartfast@magrathea.h2g2
      
      	[ myexts ]
      	basicConstraints=critical,CA:FALSE
      	keyUsage=digitalSignature
      	subjectKeyIdentifier=hash
      	authorityKeyIdentifier=hash
      
      The build process will use this to configure:
      
      	openssl req -new -nodes -utf8 -sha1 -days 36500 -batch \
      		-x509 -config x509.genkey \
      		-outform DER -out signing_key.x509 \
      		-keyout signing_key.priv
      
      to generate the key.
      
      Note that it is required that the X.509 certificate have a subjectKeyIdentifier
      and an authorityKeyIdentifier.  Without those, the certificate will be
      rejected.  These can be used to check the validity of a certificate.
      
      Note that 'make distclean' will remove signing_key.{priv,x509} and x509.genkey,
      whether or not they were generated automatically.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      d441108c
    • David Howells's avatar
      MODSIGN: Provide Kconfig options · ea0b6dcf
      David Howells authored
      Provide kernel configuration options for module signing.
      
      The following configuration options are added:
      
           CONFIG_MODULE_SIG_SHA1
           CONFIG_MODULE_SIG_SHA224
           CONFIG_MODULE_SIG_SHA256
           CONFIG_MODULE_SIG_SHA384
           CONFIG_MODULE_SIG_SHA512
      
      These select the cryptographic hash used to digest the data prior to signing.
      Additionally, the crypto module selected will be built into the kernel as it
      won't be possible to load it as a module without incurring a circular
      dependency when the kernel tries to check its signature.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      ea0b6dcf
    • David Howells's avatar
      MODSIGN: Provide gitignore and make clean rules for extra files · addbcdbb
      David Howells authored
      Provide gitignore and make clean rules for extra files to hide and clean up the
      extra files produced by module signing stuff once it is added.  Also add a
      clean up rule for the module content extractor program used to extract the data
      to be signed.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      addbcdbb
    • David Howells's avatar
      MODSIGN: Add FIPS policy · 1d0059f3
      David Howells authored
      If we're in FIPS mode, we should panic if we fail to verify the signature on a
      module or we're asked to load an unsigned module in signature enforcing mode.
      Possibly FIPS mode should automatically enable enforcing mode.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      1d0059f3
    • 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
      key.
      
      (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>
      106a4ee2
  2. 08 Oct, 2012 16 commits
    • David Howells's avatar
      X.509: Add a crypto key parser for binary (DER) X.509 certificates · c26fd69f
      David Howells authored
      Add a crypto key parser for binary (DER) encoded X.509 certificates.  The
      certificate is parsed and, if possible, the signature is verified.
      
      An X.509 key can be added like this:
      
      	# keyctl padd crypto bar @s </tmp/x509.cert
      	15768135
      
      and displayed like this:
      
      	# cat /proc/keys
      	00f09a47 I--Q---     1 perm 39390000     0     0 asymmetri bar: X509.RSA e9fd6d08 []
      
      Note that this only works with binary certificates.  PEM encoded certificates
      are ignored by the parser.
      
      Note also that the X.509 key ID is not congruent with the PGP key ID, but for
      the moment, they will match.
      
      If a NULL or "" name is given to add_key(), then the parser will generate a key
      description from the CertificateSerialNumber and Name fields of the
      TBSCertificate:
      
      	00aefc4e I--Q---     1 perm 39390000     0     0 asymmetri bfbc0cd76d050ea4:/C=GB/L=Cambridge/O=Red Hat/CN=kernel key: X509.RSA 0c688c7b []
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      c26fd69f
    • David Howells's avatar
      MPILIB: Provide a function to read raw data into an MPI · e1045992
      David Howells authored
      Provide a function to read raw data of a predetermined size into an MPI rather
      than expecting the size to be encoded within the data.  The data is assumed to
      represent an unsigned integer, and the resulting MPI will be positive.
      
      The function looks like this:
      
      	MPI mpi_read_raw_data(const void *, size_t);
      
      This is useful for reading ASN.1 integer primitives where the length is encoded
      in the ASN.1 metadata.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      e1045992
    • David Howells's avatar
      X.509: Add an ASN.1 decoder · 42d5ec27
      David Howells authored
      Add an ASN.1 BER/DER/CER decoder.  This uses the bytecode from the ASN.1
      compiler in the previous patch to inform it as to what to expect to find in the
      encoded byte stream.  The output from the compiler also tells it what functions
      to call on what tags, thus allowing the caller to retrieve information.
      
      The decoder is called as follows:
      
      	int asn1_decoder(const struct asn1_decoder *decoder,
      			 void *context,
      			 const unsigned char *data,
      			 size_t datalen);
      
      The decoder argument points to the bytecode from the ASN.1 compiler.  context
      is the caller's context and is passed to the action functions.  data and
      datalen define the byte stream to be decoded.
      
      Note that the decoder is currently limited to datalen being less than 64K.
      This reduces the amount of stack space used by the decoder because ASN.1 is a
      nested construct.  Similarly, the decoder is limited to a maximum of 10 levels
      of constructed data outside of a leaf node also in an effort to keep stack
      usage down.
      
      These restrictions can be raised if necessary.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      42d5ec27
    • David Howells's avatar
      X.509: Add simple ASN.1 grammar compiler · 4520c6a4
      David Howells authored
      Add a simple ASN.1 grammar compiler.  This produces a bytecode output that can
      be fed to a decoder to inform the decoder how to interpret the ASN.1 stream it
      is trying to parse.
      
      Action functions can be specified in the grammar by interpolating:
      
      	({ foo })
      
      after a type, for example:
      
      	SubjectPublicKeyInfo ::= SEQUENCE {
      		algorithm		AlgorithmIdentifier,
      		subjectPublicKey	BIT STRING ({ do_key_data })
      		}
      
      The decoder is expected to call these after matching this type and parsing the
      contents if it is a constructed type.
      
      The grammar compiler does not currently support the SET type (though it does
      support SET OF) as I can't see a good way of tracking which members have been
      encountered yet without using up extra stack space.
      
      Currently, the grammar compiler will fail if more than 256 bytes of bytecode
      would be produced or more than 256 actions have been specified as it uses
      8-bit jump values and action indices to keep space usage down.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      4520c6a4
    • David Howells's avatar
      X.509: Add utility functions to render OIDs as strings · 4f73175d
      David Howells authored
      Add a pair of utility functions to render OIDs as strings.  The first takes an
      encoded OID and turns it into a "a.b.c.d" form string:
      
      	int sprint_oid(const void *data, size_t datasize,
      		       char *buffer, size_t bufsize);
      
      The second takes an OID enum index and calls the first on the data held
      therein:
      
      	int sprint_OID(enum OID oid, char *buffer, size_t bufsize);
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      4f73175d
    • David Howells's avatar
      X.509: Implement simple static OID registry · a77ad6ea
      David Howells authored
      Implement a simple static OID registry that allows the mapping of an encoded
      OID to an enum value for ease of use.
      
      The OID registry index enum appears in the:
      
      	linux/oid_registry.h
      
      header file.  A script generates the registry from lines in the header file
      that look like:
      
      	<sp*>OID_foo,<sp*>/*<sp*>1.2.3.4<sp*>*/
      
      The actual OID is taken to be represented by the numbers with interpolated
      dots in the comment.
      
      All other lines in the header are ignored.
      
      The registry is queries by calling:
      
      	OID look_up_oid(const void *data, size_t datasize);
      
      This returns a number from the registry enum representing the OID if found or
      OID__NR if not.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      a77ad6ea
    • David Howells's avatar
      RSA: Fix signature verification for shorter signatures · 0b1568a4
      David Howells authored
      gpg can produce a signature file where length of signature is less than the
      modulus size because the amount of space an MPI takes up is kept as low as
      possible by discarding leading zeros.  This regularly happens for several
      modules during the build.
      
      Fix it by relaxing check in RSA verification code.
      
      Thanks to Tomas Mraz and Miloslav Trmac for help.
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      0b1568a4
    • David Howells's avatar
      RSA: Implement signature verification algorithm [PKCS#1 / RFC3447] · 612e0fe9
      David Howells authored
      Implement RSA public key cryptography [PKCS#1 / RFC3447].  At this time, only
      the signature verification algorithm is supported.  This uses the asymmetric
      public key subtype to hold its key data.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      612e0fe9
    • David Howells's avatar
      MPILIB: Reinstate mpi_cmp[_ui]() and export for RSA signature verification · 12f008b6
      David Howells authored
      Reinstate and export mpi_cmp() and mpi_cmp_ui() from the MPI library for use by
      RSA signature verification as per RFC3447 section 5.2.2 step 1.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      12f008b6
    • David Howells's avatar
      KEYS: Provide signature verification with an asymmetric key · 4ae71c1d
      David Howells authored
      Provide signature verification using an asymmetric-type key to indicate the
      public key to be used.
      
      The API is a single function that can be found in crypto/public_key.h:
      
      	int verify_signature(const struct key *key,
      			     const struct public_key_signature *sig)
      
      The first argument is the appropriate key to be used and the second argument
      is the parsed signature data:
      
      	struct public_key_signature {
      		u8 *digest;
      		u16 digest_size;
      		enum pkey_hash_algo pkey_hash_algo : 8;
      		union {
      			MPI mpi[2];
      			struct {
      				MPI s;		/* m^d mod n */
      			} rsa;
      			struct {
      				MPI r;
      				MPI s;
      			} dsa;
      		};
      	};
      
      This should be filled in prior to calling the function.  The hash algorithm
      should already have been called and the hash finalised and the output should
      be in a buffer pointed to by the 'digest' member.
      
      Any extra data to be added to the hash by the hash format (eg. PGP) should
      have been added by the caller prior to finalising the hash.
      
      It is assumed that the signature is made up of a number of MPI values.  If an
      algorithm becomes available for which this is not the case, the above structure
      will have to change.
      
      It is also assumed that it will have been checked that the signature algorithm
      matches the key algorithm.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      4ae71c1d
    • David Howells's avatar
      KEYS: Asymmetric public-key algorithm crypto key subtype · a9681bf3
      David Howells authored
      Add a subtype for supporting asymmetric public-key encryption algorithms such
      as DSA (FIPS-186) and RSA (PKCS#1 / RFC1337).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      a9681bf3
    • David Howells's avatar
      KEYS: Asymmetric key pluggable data parsers · 46c6f177
      David Howells authored
      The instantiation data passed to the asymmetric key type are expected to be
      formatted in some way, and there are several possible standard ways to format
      the data.
      
      The two obvious standards are OpenPGP keys and X.509 certificates.  The latter
      is especially useful when dealing with UEFI, and the former might be useful
      when dealing with, say, eCryptfs.
      
      Further, it might be desirable to provide formatted blobs that indicate
      hardware is to be accessed to retrieve the keys or that the keys live
      unretrievably in a hardware store, but that the keys can be used by means of
      the hardware.
      
      From userspace, the keys can be loaded using the keyctl command, for example,
      an X.509 binary certificate:
      
      	keyctl padd asymmetric foo @s <dhowells.pem
      
      or a PGP key:
      
      	keyctl padd asymmetric bar @s <dhowells.pub
      
      or a pointer into the contents of the TPM:
      
      	keyctl add asymmetric zebra "TPM:04982390582905f8" @s
      
      Inside the kernel, pluggable parsers register themselves and then get to
      examine the payload data to see if they can handle it.  If they can, they get
      to:
      
        (1) Propose a name for the key, to be used it the name is "" or NULL.
      
        (2) Specify the key subtype.
      
        (3) Provide the data for the subtype.
      
      The key type asks the parser to do its stuff before a key is allocated and thus
      before the name is set.  If successful, the parser stores the suggested data
      into the key_preparsed_payload struct, which will be either used (if the key is
      successfully created and instantiated or updated) or discarded.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      46c6f177
    • 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>
      964f3b3b
    • David Howells's avatar
      KEYS: Document asymmetric key type · 9a83b465
      David Howells authored
      In-source documentation for the asymmetric key type.  This will be located in:
      
      	Documentation/crypto/asymmetric-keys.txt
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      9a83b465
    • David Howells's avatar
      MPILIB: Provide count_leading/trailing_zeros() based on arch functions · aacf29bf
      David Howells authored
      Provide count_leading/trailing_zeros() macros based on extant arch bit scanning
      functions rather than reimplementing from scratch in MPILIB.
      
      Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x).
      
      Also move the definition to asm-generic as other people may be interested in
      using it.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      aacf29bf
    • David Howells's avatar
      KEYS: Add payload preparsing opportunity prior to key instantiate or update · cf7f601c
      David Howells authored
      Give the key type the opportunity to preparse the payload prior to the
      instantiation and update routines being called.  This is done with the
      provision of two new key type operations:
      
      	int (*preparse)(struct key_preparsed_payload *prep);
      	void (*free_preparse)(struct key_preparsed_payload *prep);
      
      If the first operation is present, then it is called before key creation (in
      the add/update case) or before the key semaphore is taken (in the update and
      instantiate cases).  The second operation is called to clean up if the first
      was called.
      
      preparse() is given the opportunity to fill in the following structure:
      
      	struct key_preparsed_payload {
      		char		*description;
      		void		*type_data[2];
      		void		*payload;
      		const void	*data;
      		size_t		datalen;
      		size_t		quotalen;
      	};
      
      Before the preparser is called, the first three fields will have been cleared,
      the payload pointer and size will be stored in data and datalen and the default
      quota size from the key_type struct will be stored into quotalen.
      
      The preparser may parse the payload in any way it likes and may store data in
      the type_data[] and payload fields for use by the instantiate() and update()
      ops.
      
      The preparser may also propose a description for the key by attaching it as a
      string to the description field.  This can be used by passing a NULL or ""
      description to the add_key() system call or the key_create_or_update()
      function.  This cannot work with request_key() as that required the description
      to tell the upcall about the key to be created.
      
      This, for example permits keys that store PGP public keys to generate their own
      name from the user ID and public key fingerprint in the key.
      
      The instantiate() and update() operations are then modified to look like this:
      
      	int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
      	int (*update)(struct key *key, struct key_preparsed_payload *prep);
      
      and the new payload data is passed in *prep, whether or not it was preparsed.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      cf7f601c
  3. 28 Sep, 2012 5 commits
    • Rusty Russell's avatar
      module: wait when loading a module which is currently initializing. · 9bb9c3be
      Rusty Russell authored
      The original module-init-tools module loader used a fnctl lock on the
      .ko file to avoid attempts to simultaneously load a module.
      Unfortunately, you can't get an exclusive fcntl lock on a read-only
      fd, making this not work for read-only mounted filesystems.
      module-init-tools has a hacky sleep-and-loop for this now.
      
      It's not that hard to wait in the kernel, and only return -EEXIST once
      the first module has finished loading (or continue loading the module
      if the first one failed to initialize for some reason).  It's also
      consistent with what we do for dependent modules which are still loading.
      Suggested-by: default avatarLucas De Marchi <lucas.demarchi@profusion.mobi>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      9bb9c3be
    • Rusty Russell's avatar
      module: fix symbol waiting when module fails before init · 6f13909f
      Rusty Russell authored
      We use resolve_symbol_wait(), which blocks if the module containing
      the symbol is still loading.  However:
      
      1) The module_wq we use is only woken after calling the modules' init
         function, but there are other failure paths after the module is
         placed in the linked list where we need to do the same thing.
      
      2) wake_up() only wakes one waiter, and our waitqueue is shared by all
         modules, so we need to wake them all.
      
      3) wake_up_all() doesn't imply a memory barrier: I feel happier calling
         it after we've grabbed and dropped the module_mutex, not just after
         the state assignment.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      6f13909f
    • David Howells's avatar
      Make most arch asm/module.h files use asm-generic/module.h · 786d35d4
      David Howells authored
      Use the mapping of Elf_[SPE]hdr, Elf_Addr, Elf_Sym, Elf_Dyn, Elf_Rel/Rela,
      ELF_R_TYPE() and ELF_R_SYM() to either the 32-bit version or the 64-bit version
      into asm-generic/module.h for all arches bar MIPS.
      
      Also, use the generic definition mod_arch_specific where possible.
      
      To this end, I've defined three new config bools:
      
       (*) HAVE_MOD_ARCH_SPECIFIC
      
           Arches define this if they don't want to use the empty generic
           mod_arch_specific struct.
      
       (*) MODULES_USE_ELF_RELA
      
           Arches define this if their modules can contain RELA records.  This causes
           the Elf_Rela mapping to be emitted and allows apply_relocate_add() to be
           defined by the arch rather than have the core emit an error message.
      
       (*) MODULES_USE_ELF_REL
      
           Arches define this if their modules can contain REL records.  This causes
           the Elf_Rel mapping to be emitted and allows apply_relocate() to be
           defined by the arch rather than have the core emit an error message.
      
      Note that it is possible to allow both REL and RELA records: m68k and mips are
      two arches that do this.
      
      With this, some arch asm/module.h files can be deleted entirely and replaced
      with a generic-y marker in the arch Kbuild file.
      
      Additionally, I have removed the bits from m32r and score that handle the
      unsupported type of relocation record as that's now handled centrally.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      786d35d4
    • Ralf Baechle's avatar
      MIPS: Fix module.c build for 32 bit · 6ede8123
      Ralf Baechle authored
      Fixes build failure introduced by "Make most arch asm/module.h files use
      asm-generic/module.h" by moving all the RELA processing code to a
      separate file to be used only for RELA processing on 64-bit kernels.
      
        CC      arch/mips/kernel/module.o
      arch/mips/kernel/module.c:250:14: error: 'reloc_handlers_rela' defined but not
      used [-Werror=unused-variable]
      cc1: all warnings being treated as errors
      
      make[6]: *** [arch/mips/kernel/module.o] Error 1
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      6ede8123
    • Matthew Garrett's avatar
      module: taint kernel when lve module is loaded · c99af375
      Matthew Garrett authored
      Cloudlinux have a product called lve that includes a kernel module. This
      was previously GPLed but is now under a proprietary license, but the
      module continues to declare MODULE_LICENSE("GPL") and makes use of some
      EXPORT_SYMBOL_GPL symbols. Forcibly taint it in order to avoid this.
      Signed-off-by: default avatarMatthew Garrett <mjg59@srcf.ucam.org>
      Cc: Alex Lyashkov <umka@cloudlinux.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@kernel.org
      c99af375
  4. 18 Sep, 2012 2 commits
  5. 17 Sep, 2012 4 commits
    • Linus Torvalds's avatar
      Merge branch 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq · 4651afbb
      Linus Torvalds authored
      Pull another workqueue fix from Tejun Heo:
       "Unfortunately, yet another late fix.  This too is discovered and fixed
        by Lai.  This bug was introduced during this merge window by commit
        25511a47 ("workqueue: reimplement CPU online rebinding to handle
        idle workers") which started using WORKER_REBIND flag for idle rebind
        too.
      
        The bug is relatively easy to trigger if the CPU rapidly goes through
        off, on and then off (and stay off).  The fix is on the safer side.
        This hasn't been on linux-next yet but I'm pushing early so that it
        can get more exposure before v3.6 release."
      
      * 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
        workqueue: always clear WORKER_REBIND in busy_worker_rebind_fn()
      4651afbb
    • Lai Jiangshan's avatar
      workqueue: always clear WORKER_REBIND in busy_worker_rebind_fn() · 960bd11b
      Lai Jiangshan authored
      busy_worker_rebind_fn() didn't clear WORKER_REBIND if rebinding failed
      (CPU is down again).  This used to be okay because the flag wasn't
      used for anything else.
      
      However, after 25511a47 "workqueue: reimplement CPU online rebinding
      to handle idle workers", WORKER_REBIND is also used to command idle
      workers to rebind.  If not cleared, the worker may confuse the next
      CPU_UP cycle by having REBIND spuriously set or oops / get stuck by
      prematurely calling idle_worker_rebind().
      
        WARNING: at /work/os/wq/kernel/workqueue.c:1323 worker_thread+0x4cd/0x5
       00()
        Hardware name: Bochs
        Modules linked in: test_wq(O-)
        Pid: 33, comm: kworker/1:1 Tainted: G           O 3.6.0-rc1-work+ #3
        Call Trace:
         [<ffffffff8109039f>] warn_slowpath_common+0x7f/0xc0
         [<ffffffff810903fa>] warn_slowpath_null+0x1a/0x20
         [<ffffffff810b3f1d>] worker_thread+0x4cd/0x500
         [<ffffffff810bc16e>] kthread+0xbe/0xd0
         [<ffffffff81bd2664>] kernel_thread_helper+0x4/0x10
        ---[ end trace e977cf20f4661968 ]---
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff810b3db0>] worker_thread+0x360/0x500
        PGD 0
        Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
        Modules linked in: test_wq(O-)
        CPU 0
        Pid: 33, comm: kworker/1:1 Tainted: G        W  O 3.6.0-rc1-work+ #3 Bochs Bochs
        RIP: 0010:[<ffffffff810b3db0>]  [<ffffffff810b3db0>] worker_thread+0x360/0x500
        RSP: 0018:ffff88001e1c9de0  EFLAGS: 00010086
        RAX: 0000000000000000 RBX: ffff88001e633e00 RCX: 0000000000004140
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009
        RBP: ffff88001e1c9ea0 R08: 0000000000000000 R09: 0000000000000001
        R10: 0000000000000002 R11: 0000000000000000 R12: ffff88001fc8d580
        R13: ffff88001fc8d590 R14: ffff88001e633e20 R15: ffff88001e1c6900
        FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000000000 CR3: 00000000130e8000 CR4: 00000000000006f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process kworker/1:1 (pid: 33, threadinfo ffff88001e1c8000, task ffff88001e1c6900)
        Stack:
         ffff880000000000 ffff88001e1c9e40 0000000000000001 ffff88001e1c8010
         ffff88001e519c78 ffff88001e1c9e58 ffff88001e1c6900 ffff88001e1c6900
         ffff88001e1c6900 ffff88001e1c6900 ffff88001fc8d340 ffff88001fc8d340
        Call Trace:
         [<ffffffff810bc16e>] kthread+0xbe/0xd0
         [<ffffffff81bd2664>] kernel_thread_helper+0x4/0x10
        Code: b1 00 f6 43 48 02 0f 85 91 01 00 00 48 8b 43 38 48 89 df 48 8b 00 48 89 45 90 e8 ac f0 ff ff 3c 01 0f 85 60 01 00 00 48 8b 53 50 <8b> 02 83 e8 01 85 c0 89 02 0f 84 3b 01 00 00 48 8b 43 38 48 8b
        RIP  [<ffffffff810b3db0>] worker_thread+0x360/0x500
         RSP <ffff88001e1c9de0>
        CR2: 0000000000000000
      
      There was no reason to keep WORKER_REBIND on failure in the first
      place - WORKER_UNBOUND is guaranteed to be set in such cases
      preventing incorrectly activating concurrency management.  Always
      clear WORKER_REBIND.
      
      tj: Updated comment and description.
      Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      960bd11b
    • Linus Torvalds's avatar
      Merge branch 'akpm' (Andrew's patch-bomb) · 08077ca8
      Linus Torvalds authored
      Merge fixes from Andrew Morton:
       "13 patches.  12 are fixes and one is a little preparatory thing for
        Andi."
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (13 commits)
        memory hotplug: fix section info double registration bug
        mm/page_alloc: fix the page address of higher page's buddy calculation
        drivers/rtc/rtc-twl.c: ensure all interrupts are disabled during probe
        compiler.h: add __visible
        pid-namespace: limit value of ns_last_pid to (0, max_pid)
        include/net/sock.h: squelch compiler warning in sk_rmem_schedule()
        slub: consider pfmemalloc_match() in get_partial_node()
        slab: fix starting index for finding another object
        slab: do ClearSlabPfmemalloc() for all pages of slab
        nbd: clear waiting_queue on shutdown
        MAINTAINERS: fix TXT maintainer list and source repo path
        mm/ia64: fix a memory block size bug
        memory hotplug: reset pgdat->kswapd to NULL if creating kernel thread fails
      08077ca8
    • qiuxishi's avatar
      memory hotplug: fix section info double registration bug · f14851af
      qiuxishi authored
      There may be a bug when registering section info.  For example, on my
      Itanium platform, the pfn range of node0 includes the other nodes, so
      other nodes' section info will be double registered, and memmap's page
      count will equal to 3.
      
        node0: start_pfn=0x100,    spanned_pfn=0x20fb00, present_pfn=0x7f8a3, => 0x000100-0x20fc00
        node1: start_pfn=0x80000,  spanned_pfn=0x80000,  present_pfn=0x80000, => 0x080000-0x100000
        node2: start_pfn=0x100000, spanned_pfn=0x80000,  present_pfn=0x80000, => 0x100000-0x180000
        node3: start_pfn=0x180000, spanned_pfn=0x80000,  present_pfn=0x80000, => 0x180000-0x200000
      
        free_all_bootmem_node()
      	register_page_bootmem_info_node()
      		register_page_bootmem_info_section()
      
      When hot remove memory, we can't free the memmap's page because
      page_count() is 2 after put_page_bootmem().
      
        sparse_remove_one_section()
      	free_section_usemap()
      		free_map_bootmem()
      			put_page_bootmem()
      
      [akpm@linux-foundation.org: add code comment]
      Signed-off-by: default avatarXishi Qiu <qiuxishi@huawei.com>
      Signed-off-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f14851af