Eric Lee / smarc-fsl-linux-kernel

20 Aug, 2019

1 commit

  • 99d5cadfd   kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE ... Browse Code »

    This is a preparatory patch for kexec_file_load() lockdown. A locked down
    kernel needs to prevent unsigned kernel images from being loaded with
    kexec_file_load(). Currently, the only way to force the signature
    verification is compiling with KEXEC_VERIFY_SIG. This prevents loading
    usigned images even when the kernel is not locked down at runtime.

    This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
    Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
    turns on the signature verification but allows unsigned images to be
    loaded. KEXEC_SIG_FORCE disallows images without a valid signature.

    Signed-off-by: Jiri Bohac
    Signed-off-by: David Howells
    Signed-off-by: Matthew Garrett
    cc: kexec@lists.infradead.org
    Signed-off-by: James Morris

    Jiri Bohac
     

24 May, 2019

1 commit

  • b4d0d230c   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 36 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public licence as published by
    the free software foundation either version 2 of the licence or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 114 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Kate Stewart
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190520170857.552531963@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

25 Apr, 2019

1 commit

  • 877b5691f   crypto: shash - remove shash_desc::flags ... Browse Code »

    The flags field in 'struct shash_desc' never actually does anything.
    The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
    However, no shash algorithm ever sleeps, making this flag a no-op.

    With this being the case, inevitably some users who can't sleep wrongly
    pass MAY_SLEEP. These would all need to be fixed if any shash algorithm
    actually started sleeping. For example, the shash_ahash_*() functions,
    which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
    from the ahash API to the shash API. However, the shash functions are
    called under kmap_atomic(), so actually they're assumed to never sleep.

    Even if it turns out that some users do need preemption points while
    hashing large buffers, we could easily provide a helper function
    crypto_shash_update_large() which divides the data into smaller chunks
    and calls crypto_shash_update() and cond_resched() for each chunk. It's
    not necessary to have a flag in 'struct shash_desc', nor is it necessary
    to make individual shash algorithms aware of this at all.

    Therefore, remove shash_desc::flags, and document that the
    crypto_shash_*() functions can be called from any context.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

09 Jun, 2017

1 commit

06 Apr, 2016

2 commits

  • bda850cd2   PKCS#7: Make trust determination dependent on contents of trust keyring ... Browse Code »

    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

    David Howells
     
  • e68503bd6   KEYS: Generalise system_verify_data() to provide access to internal content ... Browse Code »

    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

    David Howells
     

04 Mar, 2016

1 commit

13 Aug, 2015

1 commit

  • 99db44350   PKCS#7: Appropriately restrict authenticated attributes and content type ... Browse Code »

    A PKCS#7 or CMS message can have per-signature authenticated attributes
    that are digested as a lump and signed by the authorising key for that
    signature. If such attributes exist, the content digest isn't itself
    signed, but rather it is included in a special authattr which then
    contributes to the signature.

    Further, we already require the master message content type to be
    pkcs7_signedData - but there's also a separate content type for the data
    itself within the SignedData object and this must be repeated inside the
    authattrs for each signer [RFC2315 9.2, RFC5652 11.1].

    We should really validate the authattrs if they exist or forbid them
    entirely as appropriate. To this end:

    (1) Alter the PKCS#7 parser to reject any message that has more than one
    signature where at least one signature has authattrs and at least one
    that does not.

    (2) Validate authattrs if they are present and strongly restrict them.
    Only the following authattrs are permitted and all others are
    rejected:

    (a) contentType. This is checked to be an OID that matches the
    content type in the SignedData object.

    (b) messageDigest. This must match the crypto digest of the data.

    (c) signingTime. If present, we check that this is a valid, parseable
    UTCTime or GeneralTime and that the date it encodes fits within
    the validity window of the matching X.509 cert.

    (d) S/MIME capabilities. We don't check the contents.

    (e) Authenticode SP Opus Info. We don't check the contents.

    (f) Authenticode Statement Type. We don't check the contents.

    The message is rejected if (a) or (b) are missing. If the message is
    an Authenticode type, the message is rejected if (e) is missing; if
    not Authenticode, the message is rejected if (d) - (f) are present.

    The S/MIME capabilities authattr (d) unfortunately has to be allowed
    to support kernels already signed by the pesign program. This only
    affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).

    The message is also rejected if an authattr is given more than once or
    if it contains more than one element in its set of values.

    (3) Add a parameter to pkcs7_verify() to select one of the following
    restrictions and pass in the appropriate option from the callers:

    (*) VERIFYING_MODULE_SIGNATURE

    This requires that the SignedData content type be pkcs7-data and
    forbids authattrs. sign-file sets CMS_NOATTR. We could be more
    flexible and permit authattrs optionally, but only permit minimal
    content.

    (*) VERIFYING_FIRMWARE_SIGNATURE

    This requires that the SignedData content type be pkcs7-data and
    requires authattrs. In future, this will require an attribute
    holding the target firmware name in addition to the minimal set.

    (*) VERIFYING_UNSPECIFIED_SIGNATURE

    This requires that the SignedData content type be pkcs7-data but
    allows either no authattrs or only permits the minimal set.

    (*) VERIFYING_KEXEC_PE_SIGNATURE

    This only supports the Authenticode SPC_INDIRECT_DATA content type
    and requires at least an SpcSpOpusInfo authattr in addition to the
    minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
    an S/MIME capabilities authattr because the pesign program doesn't
    remove these).

    (*) VERIFYING_KEY_SIGNATURE
    (*) VERIFYING_KEY_SELF_SIGNATURE

    These are invalid in this context but are included for later use
    when limiting the use of X.509 certs.

    (4) The pkcs7_test key type is given a module parameter to select between
    the above options for testing purposes. For example:

    echo 1 >/sys/module/pkcs7_test_key/parameters/usage
    keyctl padd pkcs7_test foo @s
    Signed-off-by: David Howells
    Reviewed-by: Marcel Holtmann
    Reviewed-by: David Woodhouse

    David Howells
     

03 Sep, 2014

1 commit

  • 0aa040940   PEFILE: Relax the check on the length of the PKCS#7 cert ... Browse Code »

    Relax the check on the length of the PKCS#7 cert as it appears that the PE
    file wrapper size gets rounded up to the nearest 8.

    The debugging output looks like this:

    PEFILE: ==> verify_pefile_signature()
    PEFILE: ==> pefile_parse_binary()
    PEFILE: checksum @ 110
    PEFILE: header size = 200
    PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ]
    PEFILE: sig wrapper = { 968, 200, 2 }
    PEFILE: Signature data not PKCS#7

    The wrapper is the first 8 bytes of the hex dump inside []. This indicates a
    length of 0x968 bytes, including the wrapper header - so 0x960 bytes of
    payload.

    The ASN.1 wrapper begins [ ... 30 82 09 56 ]. That indicates an object of size
    0x956 - a four byte discrepency, presumably just padding for alignment
    purposes.

    So we just check that the ASN.1 container is no bigger than the payload and
    reduce the recorded size appropriately.

    Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within
    127 or 255 bytes. It's just about conceivable if no X.509 certs are included
    in the PKCS#7 message.

    Reported-by: Vivek Goyal
    Signed-off-by: David Howells
    Acked-by: Vivek Goyal
    Acked-by: Peter Jones
    Signed-off-by: James Morris

    David Howells
     

09 Jul, 2014

6 commits