12 Apr, 2016
6 commits
-
Move the point at which a key is determined to be trustworthy to
__key_link() so that we use the contents of the keyring being linked in to
to determine whether the key being linked in is trusted or not.What is 'trusted' then becomes a matter of what's in the keyring.
Currently, the test is done when the key is parsed, but given that at that
point we can only sensibly refer to the contents of the system trusted
keyring, we can only use that as the basis for working out the
trustworthiness of a new key.With this change, a trusted keyring is a set of keys that once the
trusted-only flag is set cannot be added to except by verification through
one of the contained keys.Further, adding a key into a trusted keyring, whilst it might grant
trustworthiness in the context of that keyring, does not automatically
grant trustworthiness in the context of a second keyring to which it could
be secondarily linked.To accomplish this, the authentication data associated with the key source
must now be retained. For an X.509 cert, this means the contents of the
AuthorityKeyIdentifier and the signature data.If system keyrings are disabled then restrict_link_by_builtin_trusted()
resolves to restrict_link_reject(). The integrity digital signature code
still works correctly with this as it was previously using
KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there
is no system keyring against which trust can be determined.Signed-off-by: David Howells
-
Make the system trusted keyring depend on the asymmetric key type as
there's not a lot of point having it if you can't then load asymmetric keys
onto it.This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as
the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to
'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't
work as the Kconfig interpreter then wrongly complains about dependency
loops.Signed-off-by: David Howells
-
Move the X.509 trust validation code out to its own file so that it can be
generalised.Signed-off-by: David Howells
-
We should call verify_signature() rather than directly calling
public_key_verify_signature() if we have a struct key to use as we
shouldn't be poking around in the private data of the key struct as that's
subtype dependent.Signed-off-by: David Howells
-
Generalise x509_request_asymmetric_key(). It doesn't really have any
dependencies on X.509 features as it uses generalised IDs and the
public_key structs that contain data extracted from X.509.Signed-off-by: David Howells
-
Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
generalised.Signed-off-by: David Howells
06 Apr, 2016
9 commits
-
Make the determination of the trustworthiness of a key dependent on whether
a key that can verify it is present in the supplied ring of trusted keys
rather than whether or not the verifying key has KEY_FLAG_TRUSTED set.verify_pkcs7_signature() will return -ENOKEY if the PKCS#7 message trust
chain cannot be verified.Signed-off-by: David Howells
-
Generalise system_verify_data() to provide access to internal content
through a callback. This allows all the PKCS#7 stuff to be hidden inside
this function and removed from the PE file parser and the PKCS#7 test key.If external content is not required, NULL should be passed as data to the
function. If the callback is not required, that can be set to NULL.The function is now called verify_pkcs7_signature() to contrast with
verify_pefile_signature() and the definitions of both have been moved into
linux/verification.h along with the key_being_used_for enum.Signed-off-by: David Howells
-
There's a bug in the code determining whether a certificate is self-signed
or not: if they have neither AKID nor SKID then we just assume that the
cert is self-signed, which may not be true.Fix this by checking that the raw subject name matches the raw issuer name
and that the public key algorithm for the key and signature are both the
same in addition to requiring that the AKID bits match.Signed-off-by: David Howells
-
Extract the signature digest for an X.509 certificate earlier, at the end
of x509_cert_parse() rather than leaving it to the callers thereof since it
has to be called anyway.Further, immediately after that, check the signature on self-signed
certificates, also rather in the callers of x509_cert_parse().We note in the x509_certificate struct the following bits of information:
(1) Whether the signature is self-signed (even if we can't check the
signature due to missing crypto).(2) Whether the key held in the certificate needs unsupported crypto to be
used. We may get a PKCS#7 message with X.509 certs that we can't make
use of - we just ignore them and give ENOPKG at the end it we couldn't
verify anything if at least one of these unusable certs are in the
chain of trust.(3) Whether the signature held in the certificate needs unsupported crypto
to be checked. We can still use the key held in this certificate,
even if we can't check the signature on it - if it is held in the
system trusted keyring, for instance. We just can't add it to a ring
of trusted keys or follow it further up the chain of trust.Making these checks earlier allows x509_check_signature() to be removed and
replaced with direct calls to public_key_verify_signature().Signed-off-by: David Howells
-
Point to the public_key_signature struct from the pkcs7_signed_info struct
rather than embedding it. This makes the code consistent with the X.509
signature handling and makes it possible to have a common cleanup function.We also save a copy of the digest in the signature without sharing the
memory with the crypto layer metadata.Signed-off-by: David Howells
-
Retain the key verification data (ie. the struct public_key_signature)
including the digest and the key identifiers.Note that this means that we need to take a separate copy of the digest in
x509_get_sig_params() rather than lumping it in with the crypto layer data.Signed-off-by: David Howells
-
Add key identifier pointers to public_key_signature struct so that they can
be used to retain the identifier of the key to be used to verify the
signature in both PKCS#7 and X.509.Signed-off-by: David Howells
-
Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.For the public key subtype, this will be a public_key_signature struct.
Signed-off-by: David Howells
-
Clean up some whitespace.
Signed-off-by: David Howells
31 Mar, 2016
1 commit
-
Pull crypto fix from Herbert Xu:
"This fixes a bug in pkcs7_validate_trust and its users where the
output value may in fact be taken from uninitialised memory"* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument
23 Mar, 2016
1 commit
-
Despite what the DocBook comment to pkcs7_validate_trust() says, the
*_trusted argument is never set to false.pkcs7_validate_trust() only positively sets *_trusted upon encountering
a trusted PKCS#7 SignedInfo block.This is quite unfortunate since its callers, system_verify_data() for
example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust.Indeed, UBSAN splats when attempting to load the uninitialized local
variable 'trusted' from system_verify_data() in pkcs7_validate_trust():UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14
load of value 82 is not a valid value for type '_Bool'
[...]
Call Trace:
[] dump_stack+0xbc/0x117
[] ? _atomic_dec_and_lock+0x169/0x169
[] ubsan_epilogue+0xd/0x4e
[] __ubsan_handle_load_invalid_value+0x111/0x158
[] ? val_to_string.constprop.12+0xcf/0xcf
[] ? x509_request_asymmetric_key+0x114/0x370
[] ? kfree+0x220/0x370
[] ? public_key_verify_signature_2+0x32/0x50
[] pkcs7_validate_trust+0x524/0x5f0
[] system_verify_data+0xca/0x170
[] ? top_trace_array+0x9b/0x9b
[] ? __vfs_read+0x279/0x3d0
[] mod_verify_sig+0x1ff/0x290
[...]The implication is that pkcs7_validate_trust() effectively grants trust
when it really shouldn't have.Fix this by explicitly setting *_trusted to false at the very beginning
of pkcs7_validate_trust().Cc:
Signed-off-by: Nicolai Stange
Signed-off-by: Herbert Xu
04 Mar, 2016
2 commits
-
Make the identifier public key and digest algorithm fields text instead of
enum.Signed-off-by: David Howells
Acked-by: Herbert Xu -
Move the RSA EMSA-PKCS1-v1_5 encoding from the asymmetric-key public_key
subtype to the rsa crypto module's pkcs1pad template. This means that the
public_key subtype no longer has any dependencies on public key type.To make this work, the following changes have been made:
(1) The rsa pkcs1pad template is now used for RSA keys. This strips off the
padding and returns just the message hash.(2) In a previous patch, the pkcs1pad template gained an optional second
parameter that, if given, specifies the hash used. We now give this,
and pkcs1pad checks the encoded message E(M) for the EMSA-PKCS1-v1_5
encoding and verifies that the correct digest OID is present.(3) The crypto driver in crypto/asymmetric_keys/rsa.c is now reduced to
something that doesn't care about what the encryption actually does
and and has been merged into public_key.c.(4) CONFIG_PUBLIC_KEY_ALGO_RSA is gone. Module signing must set
CONFIG_CRYPTO_RSA=y instead.Thoughts:
(*) Should the encoding style (eg. raw, EMSA-PKCS1-v1_5) also be passed to
the padding template? Should there be multiple padding templates
registered that share most of the code?Signed-off-by: David Howells
Signed-off-by: Tadeusz Struk
Acked-by: Herbert Xu
29 Feb, 2016
4 commits
-
The ASN.1 GeneralizedTime object carries an ISO 8601 format date and time.
The time is permitted to show midnight as 00:00 or 24:00 (the latter being
equivalent of 00:00 of the following day).The permitted value is checked in x509_decode_time() but the actual
handling is left to mktime64().Without this patch, certain X.509 certificates will be rejected and could
lead to an unbootable kernel.Note that with this patch we also permit any 24:mm:ss time and extend this
to UTCTime, which whilst not strictly correct don't permit much leeway in
fiddling date strings.Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz -
The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601
[X.680 46.3] and this apparently supports leap seconds (ie. the seconds
field is 60). It's not entirely clear that ASN.1 expects it, but we can
relax the seconds check slightly for GeneralizedTime.This results in us passing a time with sec as 60 to mktime64(), which
handles it as being a duplicate of the 0th second of the next minute.We can't really do otherwise without giving the kernel much greater
knowledge of where all the leap seconds are. Unfortunately, this would
require change the mapping of the kernel's current-time-in-seconds.UTCTime, however, only supports a seconds value in the range 00-59, but for
the sake of simplicity allow this with UTCTime also.Without this patch, certain X.509 certificates will be rejected,
potentially making a kernel unbootable.Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz -
There are still a couple of minor issues in the X.509 leap year handling:
(1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
determining whether the year is a leap year or not, I divided the year
by 100 after doing the modulus-by-100, thereby letting the compiler do
one instruction for both, and then did a modulus-by-4.Unfortunately, I then passed the now-modified year value to mktime64()
to construct a time value.Since this isn't a fast path and since mktime64() does a bunch of
divisions, just condense down to "% 400". It's also easier to read.(2) The default month length for any February where the year doesn't
divide by four exactly is obtained from the month_length[] array where
the value is 29, not 28.This is fixed by altering the table.
Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: David Woodhouse
Acked-by: Arnd Bergmann
cc: stable@vger.kernel.org -
The boolean want is not initialized and hence garbage. The default should
be false (later it is only set to true on tne sinfo->authattrs check).Found with static analysis using CoverityScan
Signed-off-by: Colin Ian King
Signed-off-by: David Howells
10 Feb, 2016
1 commit
-
This patch converts the module verification code to the new akcipher API.
Signed-off-by: Tadeusz Struk
Acked-by: Herbert Xu
Signed-off-by: David Howells
09 Feb, 2016
1 commit
-
This needs to go through the security tree so I'm reverting the
patches for now.Signed-off-by: Herbert Xu
06 Feb, 2016
1 commit
-
This patch converts the module verification code to the new akcipher API.
Signed-off-by: Tadeusz Struk
Signed-off-by: Herbert Xu
25 Jan, 2016
1 commit
-
Dave Young reported:
> Hi,
>
> I saw the warning "Missing required AuthAttr" when testing kexec,
> known issue? Idea about how to fix it?
>
> The kernel is latest linus tree plus sevral patches from Toshi to
> cleanup io resource structure.
>
> in function pkcs7_sig_note_set_of_authattrs():
> if (!test_bit(sinfo_has_content_type, &sinfo->aa_set) ||
> !test_bit(sinfo_has_message_digest, &sinfo->aa_set) ||
> (ctx->msg->data_type == OID_msIndirectData &&
> !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))) {
> pr_warn("Missing required AuthAttr\n");
> return -EBADMSG;
> }
>
> The third condition below is true:
> (ctx->msg->data_type == OID_msIndirectData &&
> !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))
>
> I signed the kernel with redhat test key like below:
> pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o /boot/vmlinuz-4.4.0-rc8+ -s --forceAnd right he is! The Authenticode specification is a paragon amongst
technical documents, and has this pearl of wisdom to offer:---------------------------------
Authenticode-Specific SignerInfo UnauthenticatedAttributes StructuresThe following Authenticode-specific data structures are present in
SignerInfo authenticated attributes.SpcSpOpusInfo
SpcSpOpusInfo is identified by SPC_SP_OPUS_INFO_OBJID
(1.3.6.1.4.1.311.2.1.12) and is defined as follows:
SpcSpOpusInfo ::= SEQUENCE {
programName [0] EXPLICIT SpcString OPTIONAL,
moreInfo [1] EXPLICIT SpcLink OPTIONAL,
} --#public--SpcSpOpusInfo has two fields:
programName
This field contains the program description:
If publisher chooses not to specify a description, the SpcString
structure contains a zero-length program name.
If the publisher chooses to specify a
description, the SpcString structure contains a Unicode string.
moreInfo
This field is set to an SPCLink structure that contains a URL for
a Web site with more information about the signer. The URL is an
ASCII string.
---------------------------------Which is to say that this is an optional *unauthenticated* field which
may be present in the Authenticated Attribute list. This is not how
pkcs7 is supposed to work, so when David implemented this, he didn't
appreciate the subtlety the original spec author was working with, and
missed the part of the sublime prose that says this Authenticated
Attribute is an Unauthenticated Attribute. As a result, the code in
question simply takes as given that the Authenticated Attributes should
be authenticated.But this one should not, individually. Because it says it's not
authenticated.It still has to hash right so the TBS digest is correct. So it is both
authenticated and unauthenticated, all at once. Truly, a wonder of
technical accomplishment.Additionally, pesign's implementation has always attempted to be
compatible with the signatures emitted from contemporary versions of
Microsoft's signtool.exe. During the initial implementation, Microsoft
signatures always produced the same values for SpcSpOpusInfo -
{U"Microsoft Windows", "http://www.microsoft.com"} - without regard to
who the signer was.Sometime between Windows 8 and Windows 8.1 they stopped including the
field in their signatures altogether, and as such pesign stopped
producing them in commits c0c4da6 and d79cb0c, sometime around June of
2012. The theory here is that anything that breaks with
pesign signatures would also be breaking with signtool.exe sigs as well,
and that'll be a more noticed problem for firmwares parsing it, so it'll
get fixed. The fact that we've done exactly this bug in Linux code is
first class, grade A irony.So anyway, we should not be checking this field for presence or any
particular value: if the field exists, it should be at the right place,
but aside from that, as long as the hash matches the field is good.Signed-off-by: Peter Jones
Tested-by: Dave Young
Signed-off-by: Herbert Xu
18 Jan, 2016
1 commit
-
Pull security subsystem updates from James Morris:
- EVM gains support for loading an x509 cert from the kernel
(EVM_LOAD_X509), into the EVM trusted kernel keyring.- Smack implements 'file receive' process-based permission checking for
sockets, rather than just depending on inode checks.- Misc enhancments for TPM & TPM2.
- Cleanups and bugfixes for SELinux, Keys, and IMA.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (41 commits)
selinux: Inode label revalidation performance fix
KEYS: refcount bug fix
ima: ima_write_policy() limit locking
IMA: policy can be updated zero times
selinux: rate-limit netlink message warnings in selinux_nlmsg_perm()
selinux: export validatetrans decisions
gfs2: Invalid security labels of inodes when they go invalid
selinux: Revalidate invalid inode security labels
security: Add hook to invalidate inode security labels
selinux: Add accessor functions for inode->i_security
security: Make inode argument of inode_getsecid non-const
security: Make inode argument of inode_getsecurity non-const
selinux: Remove unused variable in selinux_inode_init_security
keys, trusted: seal with a TPM2 authorization policy
keys, trusted: select hash algorithm for TPM2 chips
keys, trusted: fix: *do not* allow duplicate key options
tpm_ibmvtpm: properly handle interrupted packet receptions
tpm_tis: Tighten IRQ auto-probing
tpm_tis: Refactor the interrupt setup
tpm_tis: Get rid of the duplicate IRQ probing code
...
15 Dec, 2015
1 commit
-
This option creates IMA MOK and blacklist keyrings. IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy. To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that needs to go in .ima keyring must be signed by CA in
either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.IMA blacklist keyring contains all revoked IMA keys. It is consulted
before any other keyring. If the search is successful the requested
operation is rejected and error is returned to the caller.Signed-off-by: Petko Manolov
Signed-off-by: Mimi Zohar
11 Dec, 2015
1 commit
-
This file does not contain any modular related function calls. So get
rid of module.h since it drags in a lot of other headers and adds to
the preprocessing load. It does export some symbols though, so we'll
need to ensure it has export.h present instead.Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Paul Gortmaker
Signed-off-by: Herbert Xu
12 Nov, 2015
1 commit
-
This fixes CVE-2015-5327. It affects kernels from 4.3-rc1 onwards.
Fix the X.509 time validation to use month number-1 when looking up the
number of days in that month. Also put the month number validation before
doing the lookup so as not to risk overrunning the array.This can be tested by doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
Signed-off-by: James Morris
06 Nov, 2015
1 commit
-
Pull security subsystem update from James Morris:
"This is mostly maintenance updates across the subsystem, with a
notable update for TPM 2.0, and addition of Jarkko Sakkinen as a
maintainer of that"* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (40 commits)
apparmor: clarify CRYPTO dependency
selinux: Use a kmem_cache for allocation struct file_security_struct
selinux: ioctl_has_perm should be static
selinux: use sprintf return value
selinux: use kstrdup() in security_get_bools()
selinux: use kmemdup in security_sid_to_context_core()
selinux: remove pointless cast in selinux_inode_setsecurity()
selinux: introduce security_context_str_to_sid
selinux: do not check open perm on ftruncate call
selinux: change CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default
KEYS: Merge the type-specific data with the payload data
KEYS: Provide a script to extract a module signature
KEYS: Provide a script to extract the sys cert list from a vmlinux file
keys: Be more consistent in selection of union members used
certs: add .gitignore to stop git nagging about x509_certificate_list
KEYS: use kvfree() in add_key
Smack: limited capability for changing process label
TPM: remove unnecessary little endian conversion
vTPM: support little endian guests
char: Drop owner assignment from i2c_driver
...
05 Nov, 2015
1 commit
-
Pull crypto update from Herbert Xu:
"API:- Add support for cipher output IVs in testmgr
- Add missing crypto_ahash_blocksize helper
- Mark authenc and des ciphers as not allowed under FIPS.Algorithms:
- Add CRC support to 842 compression
- Add keywrap algorithm
- A number of changes to the akcipher interface:
+ Separate functions for setting public/private keys.
+ Use SG lists.Drivers:
- Add Intel SHA Extension optimised SHA1 and SHA256
- Use dma_map_sg instead of custom functions in crypto drivers
- Add support for STM32 RNG
- Add support for ST RNG
- Add Device Tree support to exynos RNG driver
- Add support for mxs-dcp crypto device on MX6SL
- Add xts(aes) support to caam
- Add ctr(aes) and xts(aes) support to qat
- A large set of fixes from Russell King for the marvell/cesa driver"* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (115 commits)
crypto: asymmetric_keys - Fix unaligned access in x509_get_sig_params()
crypto: akcipher - Don't #include crypto/public_key.h as the contents aren't used
hwrng: exynos - Add Device Tree support
hwrng: exynos - Fix missing configuration after suspend to RAM
hwrng: exynos - Add timeout for waiting on init done
dt-bindings: rng: Describe Exynos4 PRNG bindings
crypto: marvell/cesa - use __le32 for hardware descriptors
crypto: marvell/cesa - fix missing cpu_to_le32() in mv_cesa_dma_add_op()
crypto: marvell/cesa - use memcpy_fromio()/memcpy_toio()
crypto: marvell/cesa - use gfp_t for gfp flags
crypto: marvell/cesa - use dma_addr_t for cur_dma
crypto: marvell/cesa - use readl_relaxed()/writel_relaxed()
crypto: caam - fix indentation of close braces
crypto: caam - only export the state we really need to export
crypto: caam - fix non-block aligned hash calculation
crypto: caam - avoid needlessly saving and restoring caam_hash_ctx
crypto: caam - print errno code when hash registration fails
crypto: marvell/cesa - fix memory leak
crypto: marvell/cesa - fix first-fragment handling in mv_cesa_ahash_dma_last_req()
crypto: marvell/cesa - rearrange handling for sw padded hashes
...
21 Oct, 2015
1 commit
-
Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.Signed-off-by: David Howells
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net
20 Oct, 2015
1 commit
-
x509_get_sig_params() has the same code pattern as the one in
pkcs7_verify() that is fixed by commit 62f57d05e287 ("crypto: pkcs7 - Fix
unaligned access in pkcs7_verify()") so apply a similar fix here: make
sure that desc is pointing at an algined value past the digest_size,
and take alignment values into consideration when doing kzalloc()Signed-off-by: Sowmini Varadhan
Acked-by: David Howells
Signed-off-by: Herbert Xu
14 Oct, 2015
1 commit
-
On sparc, we see unaligned access messages on each modprobe[-r]:
Kernel unaligned access at TPC[6ad9b4] pkcs7_verify [..]
Kernel unaligned access at TPC[6a5484] crypto_shash_finup [..]
Kernel unaligned access at TPC[6a5390] crypto_shash_update [..]
Kernel unaligned access at TPC[10150308] sha1_sparc64_update [..]
Kernel unaligned access at TPC[101501ac] __sha1_sparc64_update [..]These ware triggered by mod_verify_sig() invocations of pkcs_verify(), and
are are being caused by an unaligned desc at (sha1, digest_size is 0x14)
desc = digest + digest_size;To fix this, pkcs7_verify needs to make sure that desc is pointing
at an aligned value past the digest_size, and kzalloc appropriately,
taking alignment values into consideration.Signed-off-by: Sowmini Varadhan
Signed-off-by: Herbert Xu
25 Sep, 2015
1 commit
-
Don't strip leading zeros from the crypto key ID when using it to construct
the struct key description as the signature in kernels up to and including
4.2 matched this aspect of the key. This means that 1 in 256 keys won't
actually match if their key ID begins with 00.The key ID is stored in the module signature as binary and so must be
converted to text in order to invoke request_key() - but it isn't stripped
at this point.Something like this is likely to be observed in dmesg when the key is loaded:
[ 1.572423] Loaded X.509 cert 'Build time autogenerated kernel
key: 62a7c3d2da278be024da4af8652c071f3fea33'followed by this when we try and use it:
[ 1.646153] Request for unknown module key 'Build time autogenerated
kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11The 'Loaded' line should show an extra '00' on the front of the hex string.
This problem should not affect 4.3-rc1 and onwards because there the key
should be matched on one of its auxiliary identities rather than the key
struct's description string.Reported-by: Arjan van de Ven
Reported-by: Andy Whitcroft
Signed-off-by: David Howells
21 Sep, 2015
1 commit
-
hour, min and sec are unsigned int and they can never be less than zero.
Signed-off-by: Sudip Mukherjee
Signed-off-by: Herbert Xu
01 Sep, 2015
1 commit
-
Add OIDs for sha224, sha284 and sha512 hash algos and use them to select
the hashing algorithm. Without this, something like the following error
might get written to dmesg:[ 31.829322] PKCS7: Unknown OID: [32] 2.16.840.1.101.3.4.2.3
[ 31.829328] PKCS7: Unknown OID: [180] 2.16.840.1.101.3.4.2.3
[ 31.829330] Unsupported digest algo: 55Where the 55 on the third line is OID__NR indicating an unknown OID.
Reported-by: Valdis Kletnieks
Signed-off-by: David Howells
Tested-By: Valdis Kletnieks
Signed-off-by: James Morris
13 Aug, 2015
1 commit
-
Add a MODULE_LICENSE() line to the PKCS#7 test key module to fix this
warning:WARNING: modpost: missing MODULE_LICENSE() in
crypto/asymmetric_keys/pkcs7_test_key.oWhilst we're at it, also add a module description.
Reported-by: James Morris
Signed-off-by: David Howells