summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'modules-next' of ↵Linus Torvalds2012-10-14128-594/+6799
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull module signing support from Rusty Russell: "module signing is the highlight, but it's an all-over David Howells frenzy..." Hmm "Magrathea: Glacier signing key". Somebody has been reading too much HHGTTG. * 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (37 commits) X.509: Fix indefinite length element skip error handling X.509: Convert some printk calls to pr_devel asymmetric keys: fix printk format warning MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checking MODSIGN: Make mrproper should remove generated files. MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certs MODSIGN: Use the same digest for the autogen key sig as for the module sig MODSIGN: Sign modules during the build process MODSIGN: Provide a script for generating a key ID from an X.509 cert MODSIGN: Implement module signature checking MODSIGN: Provide module signing public keys to the kernel MODSIGN: Automatically generate module signing keys if missing MODSIGN: Provide Kconfig options MODSIGN: Provide gitignore and make clean rules for extra files MODSIGN: Add FIPS policy module: signature checking hook X.509: Add a crypto key parser for binary (DER) X.509 certificates MPILIB: Provide a function to read raw data into an MPI X.509: Add an ASN.1 decoder X.509: Add simple ASN.1 grammar compiler ...
| * X.509: Fix indefinite length element skip error handlingDavid Howells2012-10-101-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | asn1_find_indefinite_length() returns an error indicator of -1, which the caller asn1_ber_decoder() places in a size_t (which is usually unsigned) and then checks to see whether it is less than 0 (which it can't be). This can lead to the following warning: lib/asn1_decoder.c:320 asn1_ber_decoder() warn: unsigned 'len' is never less than zero. Instead, asn1_find_indefinite_length() update the caller's idea of the data cursor and length separately from returning the error code. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * X.509: Convert some printk calls to pr_develDavid Howells2012-10-101-3/+3
| | | | | | | | | | | | | | | | Some debugging printk() calls should've been converted to pr_devel() calls. Do that now. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * asymmetric keys: fix printk format warningRandy Dunlap2012-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix printk format warning in x509_cert_parser.c: crypto/asymmetric_keys/x509_cert_parser.c: In function 'x509_note_OID': crypto/asymmetric_keys/x509_cert_parser.c:113:3: warning: format '%zu' expects type 'size_t', but argument 2 has type 'long unsigned int' Builds cleanly on i386 and x86_64. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: David Howells <dhowells@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: linux-crypto@vger.kernel.org Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checkingDavid Howells2012-10-103-20/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Make mrproper should remove generated files.Rusty Russell2012-10-102-2/+4
| | | | | | | | | | | | | | It doesn't, because the clean targets don't include kernel/Makefile, and because two files were missing from the list. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certsDavid Howells2012-10-101-0/+1
| | | | | | | | | | | | | | | | Place an indication that the certificate should use utf8 strings into the x509.genkey template generated by kernel/Makefile. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Use the same digest for the autogen key sig as for the module sigDavid Howells2012-10-101-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Sign modules during the build processDavid Howells2012-10-102-1/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Provide a script for generating a key ID from an X.509 certDavid Howells2012-10-101-0/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Implement module signature checkingDavid Howells2012-10-102-1/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (minor Kconfig fix)
| * MODSIGN: Provide module signing public keys to the kernelDavid Howells2012-10-103-2/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Automatically generate module signing keys if missingDavid Howells2012-10-101-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Provide Kconfig optionsDavid Howells2012-10-101-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Provide gitignore and make clean rules for extra filesDavid Howells2012-10-102-0/+15
| | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MODSIGN: Add FIPS policyDavid Howells2012-10-101-0/+4
| | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * module: signature checking hookRusty Russell2012-10-107-1/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * X.509: Add a crypto key parser for binary (DER) X.509 certificatesDavid Howells2012-10-088-0/+832
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MPILIB: Provide a function to read raw data into an MPIDavid Howells2012-10-082-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * X.509: Add an ASN.1 decoderDavid Howells2012-10-083-0/+503
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * X.509: Add simple ASN.1 grammar compilerDavid Howells2012-10-087-0/+1721
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * X.509: Add utility functions to render OIDs as stringsDavid Howells2012-10-082-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * X.509: Implement simple static OID registryDavid Howells2012-10-086-1/+410
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * RSA: Fix signature verification for shorter signaturesDavid Howells2012-10-081-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Milan Broz <mbroz@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * RSA: Implement signature verification algorithm [PKCS#1 / RFC3447]David Howells2012-10-084-0/+279
| | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MPILIB: Reinstate mpi_cmp[_ui]() and export for RSA signature verificationDavid Howells2012-10-082-0/+71
| | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * KEYS: Provide signature verification with an asymmetric keyDavid Howells2012-10-083-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * KEYS: Asymmetric public-key algorithm crypto key subtypeDavid Howells2012-10-085-0/+250
| | | | | | | | | | | | | | | | Add a subtype for supporting asymmetric public-key encryption algorithms such as DSA (FIPS-186) and RSA (PKCS#1 / RFC1337). Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * KEYS: Asymmetric key pluggable data parsersDavid Howells2012-10-082-1/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * KEYS: Implement asymmetric key typeDavid Howells2012-10-088-0/+273
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * KEYS: Document asymmetric key typeDavid Howells2012-10-081-0/+312
| | | | | | | | | | | | | | | | | | In-source documentation for the asymmetric key type. This will be located in: Documentation/crypto/asymmetric-keys.txt Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MPILIB: Provide count_leading/trailing_zeros() based on arch functionsDavid Howells2012-10-084-139/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David 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: Rusty Russell <rusty@rustcorp.com.au>
| * KEYS: Add payload preparsing opportunity prior to key instantiate or updateDavid Howells2012-10-0815-102/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * module: wait when loading a module which is currently initializing.Rusty Russell2012-09-281-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lucas De Marchi <lucas.demarchi@profusion.mobi> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * module: fix symbol waiting when module fails before initRusty Russell2012-09-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Rusty Russell <rusty@rustcorp.com.au>
| * Make most arch asm/module.h files use asm-generic/module.hDavid Howells2012-09-2857-224/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: David Howells <dhowells@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * MIPS: Fix module.c build for 32 bitRalf Baechle2012-09-283-120/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * module: taint kernel when lve module is loadedMatthew Garrett2012-09-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Alex Lyashkov <umka@cloudlinux.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org
* | x86, boot: Explicitly include autoconf.h for hostprogsMatt Fleming2012-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hostprogs need access to the CONFIG_* symbols found in include/generated/autoconf.h. But commit abbf1590de22 ("UAPI: Partition the header include path sets and add uapi/ header directories") replaced $(LINUXINCLUDE) with $(USERINCLUDE) which doesn't contain the necessary include paths. This has the undesirable effect of breaking the EFI boot stub because the #ifdef CONFIG_EFI_STUB code in arch/x86/boot/tools/build.c is never compiled. It should also be noted that because $(USERINCLUDE) isn't exported by the top-level Makefile it's actually empty in arch/x86/boot/Makefile. Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@kernel.org> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | perf: Fix UAPI falloutIngo Molnar2012-10-1410-11/+11
| | | | | | | | | | | | | | | | | | | | The UAPI commits forgot to test tooling builds such as tools/perf/, and this fixes the fallout. Manual conversion. Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'late-for-linus' of git://git.linaro.org/people/rmk/linux-armLinus Torvalds2012-10-1363-1722/+1800
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull ARM update from Russell King: "This is the final round of stuff for ARM, left until the end of the merge window to reduce the number of conflicts. This set contains the ARM part of David Howells UAPI changes, and a fix to the ordering of 'select' statements in ARM Kconfig files (see the appropriate commit for why this happened - thanks to Andrew Morton for pointing out the problem.) I've left this as long as I dare for this window to avoid conflicts, and I regenerated the config patch yesterday, posting it to our mailing list for review and testing. I have several acks which include successful test reports for it. However, today I notice we've got new conflicts with previously unseen code... though that conflict should be trivial (it's my changes vs a one liner.)" * 'late-for-linus' of git://git.linaro.org/people/rmk/linux-arm: ARM: config: make sure that platforms are ordered by option string ARM: config: sort select statements alphanumerically UAPI: (Scripted) Disintegrate arch/arm/include/asm Fix up fairly conflict in arch/arm/Kconfig (the select re-organization vs recent addition of GENERIC_KERNEL_EXECVE)
| * \ Merge branch 'config' into late-for-linusRussell King2012-10-1339-795/+793
| |\ \
| | * | ARM: config: make sure that platforms are ordered by option stringRussell King2012-10-131-38/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The large platform selection choice should be sorted by option string so it's easy to find the platform you're looking for. Fix the few options which are out of this order. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | ARM: config: sort select statements alphanumericallyRussell King2012-10-1339-767/+765
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As suggested by Andrew Morton: This is a pet peeve of mine. Any time there's a long list of items (header file inclusions, kconfig entries, array initalisers, etc) and someone wants to add a new item, they *always* go and stick it at the end of the list. Guys, don't do this. Either put the new item into a randomly-chosen position or, probably better, alphanumerically sort the list. lets sort all our select statements alphanumerically. This commit was created by the following perl: while (<>) { while (/\\\s*$/) { $_ .= <>; } undef %selects if /^\s*config\s+/; if (/^\s+select\s+(\w+).*/) { if (defined($selects{$1})) { if ($selects{$1} eq $_) { print STDERR "Warning: removing duplicated $1 entry\n"; } else { print STDERR "Error: $1 differently selected\n". "\tOld: $selects{$1}\n". "\tNew: $_\n"; exit 1; } } $selects{$1} = $_; next; } if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or /^endif/ or /^endchoice/)) { foreach $k (sort (keys %selects)) { print "$selects{$k}"; } undef %selects; } print; } if (%selects) { foreach $k (sort (keys %selects)) { print "$selects{$k}"; } } It found two duplicates: Warning: removing duplicated S5P_SETUP_MIPIPHY entry Warning: removing duplicated HARDIRQS_SW_RESEND entry and they are identical duplicates, hence the shrinkage in the diffstat of two lines. We have four testers reporting success of this change (Tony, Stephen, Linus and Sekhar.) Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | UAPI: (Scripted) Disintegrate arch/arm/include/asmDavid Howells2012-10-1224-926/+1006
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* | | Merge tag 'disintegrate-main-20121013' of ↵Linus Torvalds2012-10-13584-30367/+32928
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.infradead.org/users/dhowells/linux-headers Pull UAPI disintegration for include/linux/{,byteorder/}*.h from David Howells: "The patches contained herein do the following: (1) Remove kernel-only stuff in linux/ppp-comp.h from the UAPI. I checked this with Paul Mackerras before I created the patch and he suggested some extra bits to unexport. (2) Remove linux/blk_types.h entirely from the UAPI as none of it is userspace applicable, and remove from the UAPI that part of linux/fs.h that was the reason for linux/blk_types.h being exported in the first place. I discussed this with Jens Axboe before creating the patch. (3) The big patch of the series to disintegrate include/linux/*.h as a unit. This could be split up, though there would be collisions in moving stuff between the two Kbuild files when the parts are merged as that file is sorted alphabetically rather than being grouped by subsystem. Of this set of headers, 17 files have changed in the UAPI exported region since the 4th and only 8 since the 9th so there isn't much change in this area - as one might expect. It should be pretty obvious and straightforward if it does come to fixing up: stuff in __KERNEL__ guards stays where it is and stuff outside moves to the same file in the include/uapi/linux/ directory. If a new file appears then things get a bit more complicated as the "headers +=" line has to move to include/uapi/linux/Kbuild. Only one new file has appeared since the 9th and I judge this type of event relatively unlikely. (4) A patch to disintegrate include/linux/byteorder/*.h as a unit. Signed-off-by: David Howells <dhowells@redhat.com>" * tag 'disintegrate-main-20121013' of git://git.infradead.org/users/dhowells/linux-headers: UAPI: (Scripted) Disintegrate include/linux/byteorder UAPI: (Scripted) Disintegrate include/linux UAPI: Unexport linux/blk_types.h UAPI: Unexport part of linux/ppp-comp.h
| * | | UAPI: (Scripted) Disintegrate include/linux/byteorderDavid Howells2012-10-136-206/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
| * | | UAPI: (Scripted) Disintegrate include/linuxDavid Howells2012-10-13578-30108/+32659
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
| * | | UAPI: Unexport linux/blk_types.hDavid Howells2012-10-132-61/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that was linux/blk_types.h incorrectly exported to fix up some missing bits required by the exported parts of linux/fs.h (READ, WRITE, READA, etc.). So unexport linux/blk_types.h and unexport the relevant bits of linux/fs.h. Signed-off-by: David Howells <dhowells@redhat.com> cc: Jens Axboe <jaxboe@fusionio.com> cc: Tejun Heo <tj@kernel.org> cc: Al Viro <viro@ZenIV.linux.org.uk>
| * | | UAPI: Unexport part of linux/ppp-comp.hDavid Howells2012-10-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unexport part of linux/ppp-comp.h as userspace can't make use of that bit. Signed-off-by: David Howells <dhowells@redhat.com> cc: Paul Mackerras <paulus@samba.org> cc: David Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud