Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 17 7月, 2014 3 次提交
  3. 24 11月, 2013 1 次提交
    • L
      Revert "KEYS: verify a certificate is signed by a 'trusted' key" · 4c1cc40a
      由 Linus Torvalds 提交于 
      This reverts commit 09fbc473, which
caused the following build errors:

  crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’:
  crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function)
   ret = x509_validate_trust(cert, system_trusted_keyring);
                                   ^
  crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in

reported by Jim Davis. Mimi says:

 "I made the classic mistake of requesting this patch to be upstreamed
  at the last second, rather than waiting until the next open window.

  At this point, the best course would probably be to revert the two
  commits and fix them for the next open window"
Reported-by: NJim Davis <jim.epost@gmail.com>
Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4c1cc40a
  5. 01 11月, 2013 1 次提交
    • D
      KEYS: The RSA public key algorithm needs to select MPILIB · dbed7141
      由 David Howells 提交于 
      The RSA public key algorithm needs to select MPILIB directly in Kconfig as the
'select' directive is not recursive and is thus MPILIB is not enabled by
selecting MPILIB_EXTRA.

Without this, the following errors can occur:

	crypto/built-in.o: In function `RSA_verify_signature':
	rsa.c:(.text+0x1d347): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d354): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d36e): undefined reference to `mpi_cmp_ui'
	rsa.c:(.text+0x1d382): undefined reference to `mpi_cmp'
	rsa.c:(.text+0x1d391): undefined reference to `mpi_alloc'
	rsa.c:(.text+0x1d3b0): undefined reference to `mpi_powm'
	rsa.c:(.text+0x1d3c3): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d3d8): undefined reference to `mpi_get_buffer'
	rsa.c:(.text+0x1d4d4): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d503): undefined reference to `mpi_get_nbits'
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      dbed7141
  7. 26 10月, 2013 2 次提交
  9. 07 10月, 2013 1 次提交
    • J
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      由 James Yonan 提交于 
      When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.

Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.

This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).

Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.

We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.

crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
("Os") because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.

Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.

As we use ("Os"), this patch also provides a loop-free "fast-path" for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.

This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].

  [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
  [2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: NJames Yonan <james@openvpn.net>
Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6bf37e5a
  11. 26 9月, 2013 10 次提交
  13. 25 9月, 2013 2 次提交
  15. 22 4月, 2013 1 次提交
    • C
      X.509: Support parse long form of length octets in Authority Key Identifier · 04b00bdb
      由 Chun-Yi Lee 提交于 
      Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
   The example certificate demos/tunala/A-server.pem in openssl source:

X509v3 Authority Key Identifier:
    keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
    DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
    serial:00

Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:

[   12.061147] X.509: Extension: 47
[   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)

So, this patch add the parsing rule for support long form format against
Authority Key Identifier.

v3:
Changed the size check in "Short Form length" case, we allow v[3] smaller
then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
are also possible attach in AuthorityKeyIdentifier sequence.

v2:
 - Removed comma from author's name.
 - Moved 'Short Form length' comment inside the if-body.
 - Changed the type of sub to size_t.
 - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
 - Moved the key_len's value assignment before alter v.
 - Fixed the typo of octets.
 - Add 2 to v before entering the loop for calculate the length.
 - Removed the comment of check vlen.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NChun-Yi Lee <jlee@suse.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      04b00bdb
  17. 10 10月, 2012 3 次提交
  19. 08 10月, 2012 7 次提交
    • D
      X.509: Add a crypto key parser for binary (DER) X.509 certificates · c26fd69f
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c26fd69f
    • D
      RSA: Fix signature verification for shorter signatures · 0b1568a4
      由 David Howells 提交于 
      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: NMilan Broz <mbroz@redhat.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      0b1568a4
    • D
      RSA: Implement signature verification algorithm [PKCS#1 / RFC3447] · 612e0fe9
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      612e0fe9
    • D
      KEYS: Provide signature verification with an asymmetric key · 4ae71c1d
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      4ae71c1d
    • D
      KEYS: Asymmetric public-key algorithm crypto key subtype · a9681bf3
      由 David Howells 提交于 
      Add a subtype for supporting asymmetric public-key encryption algorithms such
as DSA (FIPS-186) and RSA (PKCS#1 / RFC1337).
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      a9681bf3
    • D
      KEYS: Asymmetric key pluggable data parsers · 46c6f177
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      46c6f177
    • D
      KEYS: Implement asymmetric key type · 964f3b3b
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      964f3b3b