17 Aug, 2022

1 commit

  • [ Upstream commit 0815291a8fd66cdcf7db1445d4d99b0d16065829 ]

    The signature verification of SM2 needs to add the Za value and
    recalculate sig->digest, which requires the detection of the pkey_algo
    in public_key_verify_signature(). As Eric Biggers said, the pkey_algo
    field in sig is attacker-controlled and should be use pkey->pkey_algo
    instead of sig->pkey_algo, and secondly, if sig->pkey_algo is NULL, it
    will also cause signature verification failure.

    The software_key_determine_akcipher() already forces the algorithms
    are matched, so the SM3 algorithm is enforced in the SM2 signature,
    although this has been checked, we still avoid using any algorithm
    information in the signature as input.

    Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
    Reported-by: Eric Biggers
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Tianjia Zhang
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen
    Signed-off-by: Sasha Levin

    Tianjia Zhang
     

08 Apr, 2022

2 commits

  • commit 590bfb57b2328951d5833979e7ca1d5fde2e609a upstream.

    It is insecure to allow arbitrary hash algorithms and signature
    encodings to be used with arbitrary signature algorithms. Notably,
    ECDSA, ECRDSA, and SM2 all sign/verify raw hash values and don't
    disambiguate between different hash algorithms like RSA PKCS#1 v1.5
    padding does. Therefore, they need to be restricted to certain sets of
    hash algorithms (ideally just one, but in practice small sets are used).
    Additionally, the encoding is an integral part of modern signature
    algorithms, and is not supposed to vary.

    Therefore, tighten the checks of hash_algo and encoding done by
    software_key_determine_akcipher().

    Also rearrange the parameters to software_key_determine_akcipher() to
    put the public_key first, as this is the most important parameter and it
    often determines everything else.

    Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys")
    Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
    Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm")
    Cc: stable@vger.kernel.org
    Tested-by: Stefan Berger
    Tested-by: Tianjia Zhang
    Signed-off-by: Eric Biggers
    Reviewed-by: Vitaly Chikunov
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     
  • commit 2abc9c246e0548e52985b10440c9ea3e9f65f793 upstream.

    Most callers of public_key_verify_signature(), including most indirect
    callers via verify_signature() as well as pkcs7_verify_sig_chain(),
    don't check that public_key_signature::pkey_algo matches
    public_key::pkey_algo. These should always match. However, a malicious
    signature could intentionally declare an unintended algorithm. It is
    essential that such signatures be rejected outright, or that the
    algorithm of the *key* be used -- not the algorithm of the signature as
    that would allow attackers to choose the algorithm used.

    Currently, public_key_verify_signature() correctly uses the key's
    algorithm when deciding which akcipher to allocate. That's good.
    However, it uses the signature's algorithm when deciding whether to do
    the first step of SM2, which is incorrect. Also, v4.19 and older
    kernels used the signature's algorithm for the entire process.

    Prevent such errors by making public_key_verify_signature() enforce that
    the signature's algorithm (if given) matches the key's algorithm.

    Also remove two checks of this done by callers, which are now redundant.

    Cc: stable@vger.kernel.org
    Tested-by: Stefan Berger
    Tested-by: Tianjia Zhang
    Signed-off-by: Eric Biggers
    Reviewed-by: Vitaly Chikunov
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     

24 Aug, 2021

1 commit

  • Add support for using elliptic curve keys for signing modules. It uses
    a NIST P384 (secp384r1) key if the user chooses an elliptic curve key
    and will have ECDSA support built into the kernel.

    Note: A developer choosing an ECDSA key for signing modules should still
    delete the signing key (rm certs/signing_key.*) when building an older
    version of a kernel that only supports RSA keys. Unless kbuild automati-
    cally detects and generates a new kernel module key, ECDSA-signed kernel
    modules will fail signature verification.

    Cc: David Howells
    Cc: David Woodhouse
    Signed-off-by: Stefan Berger
    Reviewed-by: Jarkko Sakkinen
    Tested-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Stefan Berger
     

26 Mar, 2021

3 commits

  • Prepare the x509 parser to accept NIST P384 certificates and add the
    OID for ansip384r1, which is the identifier for NIST P384.

    Summary of changes:

    * crypto/asymmetric_keys/x509_cert_parser.c
    - prepare x509 parser to load NIST P384

    * include/linux/oid_registry.h
    - add OID_ansip384r1

    Signed-off-by: Saulo Alessandre
    Tested-by: Stefan Berger
    Signed-off-by: Herbert Xu

    Saulo Alessandre
     
  • Add support for parsing of x509 certificates that contain ECDSA keys,
    such as NIST P256, that have been signed by a CA using any of the
    current SHA hash algorithms.

    Cc: David Howells
    Cc: keyrings@vger.kernel.org
    Signed-off-by: Stefan Berger
    Signed-off-by: Herbert Xu

    Stefan Berger
     
  • Detect whether a key is an sm2 type of key by its OID in the parameters
    array rather than assuming that everything under OID_id_ecPublicKey
    is sm2, which is not the case.

    Cc: David Howells
    Cc: keyrings@vger.kernel.org
    Signed-off-by: Stefan Berger
    Reviewed-by: Tianjia Zhang
    Tested-by: Tianjia Zhang
    Signed-off-by: Herbert Xu

    Stefan Berger
     

24 Feb, 2021

1 commit

  • Pull keyring updates from David Howells:
    "Here's a set of minor keyrings fixes/cleanups that I've collected from
    various people for the upcoming merge window.

    A couple of them might, in theory, be visible to userspace:

    - Make blacklist_vet_description() reject uppercase letters as they
    don't match the all-lowercase hex string generated for a blacklist
    search.

    This may want reconsideration in the future, but, currently, you
    can't add to the blacklist keyring from userspace and the only
    source of blacklist keys generates lowercase descriptions.

    - Fix blacklist_init() to use a new KEY_ALLOC_* flag to indicate that
    it wants KEY_FLAG_KEEP to be set rather than passing KEY_FLAG_KEEP
    into keyring_alloc() as KEY_FLAG_KEEP isn't a valid alloc flag.

    This isn't currently a problem as the blacklist keyring isn't
    currently writable by userspace.

    The rest of the patches are cleanups and I don't think they should
    have any visible effect"

    * tag 'keys-misc-20210126' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    watch_queue: rectify kernel-doc for init_watch()
    certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID
    certs: Fix blacklist flag type confusion
    PKCS#7: Fix missing include
    certs: Fix blacklisted hexadecimal hash string check
    certs/blacklist: fix kernel doc interface issue
    crypto: public_key: Remove redundant header file from public_key.h
    keys: remove trailing semicolon in macro definition
    crypto: pkcs7: Use match_string() helper to simplify the code
    PKCS#7: drop function from kernel-doc pkcs7_validate_trust_one
    encrypted-keys: Replace HTTP links with HTTPS ones
    crypto: asymmetric_keys: fix some comments in pkcs7_parser.h
    KEYS: remove redundant memset
    security: keys: delete repeated words in comments
    KEYS: asymmetric: Fix kerneldoc
    security/keys: use kvfree_sensitive()
    watch_queue: Drop references to /dev/watch_queue
    keys: Remove outdated __user annotations
    security: keys: Fix fall-through warnings for Clang

    Linus Torvalds
     

16 Feb, 2021

1 commit


22 Jan, 2021

4 commits

  • match_string() returns the array index of a matching string.
    Use it instead of the open-coded implementation.

    Signed-off-by: YueHaibing
    Signed-off-by: David Howells
    Reviewed-by: Ben Boeckel

    YueHaibing
     
  • The function is a static function, so no needs add into kernel-doc. and
    we could avoid warning:
    crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or
    member 'pkcs7' not described in 'pkcs7_validate_trust_one'
    crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or
    member 'sinfo' not described in 'pkcs7_validate_trust_one'
    crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or
    member 'trust_keyring' not described in 'pkcs7_validate_trust_one'

    Signed-off-by: Alex Shi
    Signed-off-by: David Howells
    Reviewed-by: Ben Boeckel
    Cc: Herbert Xu
    Cc: "David S. Miller"
    Cc: keyrings@vger.kernel.org
    Cc: linux-crypto@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org

    Alex Shi
     
  • Drop the doubled word "the" in a comment.
    Change "THis" to "This".

    Signed-off-by: Randy Dunlap
    Signed-off-by: David Howells
    Reviewed-by: Ben Boeckel
    Cc: keyrings@vger.kernel.org

    Randy Dunlap
     
  • Fix W=1 compile warnings (invalid kerneldoc):

    crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter or member 'kid1' not described in 'asymmetric_key_id_same'
    crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter or member 'kid2' not described in 'asymmetric_key_id_same'
    crypto/asymmetric_keys/asymmetric_type.c:160: warning: Excess function parameter 'kid_1' description in 'asymmetric_key_id_same'
    crypto/asymmetric_keys/asymmetric_type.c:160: warning: Excess function parameter 'kid_2' description in 'asymmetric_key_id_same'

    Signed-off-by: Krzysztof Kozlowski
    Signed-off-by: David Howells
    Acked-by: Randy Dunlap
    Reviewed-by: Ben Boeckel
    Reviewed-by: Jarkko Sakkinen

    Krzysztof Kozlowski
     

21 Jan, 2021

1 commit

  • On the following call path, `sig->pkey_algo` is not assigned
    in asymmetric_key_verify_signature(), which causes runtime
    crash in public_key_verify_signature().

    keyctl_pkey_verify
    asymmetric_key_verify_signature
    verify_signature
    public_key_verify_signature

    This patch simply check this situation and fixes the crash
    caused by NULL pointer.

    Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
    Reported-by: Tobias Markus
    Signed-off-by: Tianjia Zhang
    Signed-off-by: David Howells
    Reviewed-and-tested-by: Toke Høiland-Jørgensen
    Tested-by: João Fonseca
    Acked-by: Jarkko Sakkinen
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Linus Torvalds

    Tianjia Zhang
     

31 Dec, 2020

1 commit

  • The function derive_pub_key() should be calling memzero_explicit()
    instead of memset() in case the complier decides to optimize away the
    call to memset() because it "knows" no one is going to touch the memory
    anymore.

    Cc: stable
    Reported-by: Ilil Blum Shem-Tov
    Tested-by: Ilil Blum Shem-Tov
    Signed-off-by: Greg Kroah-Hartman
    Link: https://lore.kernel.org/r/X8ns4AfwjKudpyfe@kroah.com
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

20 Nov, 2020

1 commit

  • Currently contains declarations for both SHA-1 and SHA-2,
    and contains declarations for SHA-3.

    This organization is inconsistent, but more importantly SHA-1 is no
    longer considered to be cryptographically secure. So to the extent
    possible, SHA-1 shouldn't be grouped together with any of the other SHA
    versions, and usage of it should be phased out.

    Therefore, split into two headers and
    , and make everyone explicitly specify whether they want
    the declarations for SHA-1, SHA-2, or both.

    This avoids making the SHA-1 declarations visible to files that don't
    want anything to do with SHA-1. It also prepares for potentially moving
    sha1.h into a new insecure/ or dangerous/ directory.

    Signed-off-by: Eric Biggers
    Acked-by: Ard Biesheuvel
    Acked-by: Jason A. Donenfeld
    Signed-off-by: Herbert Xu

    Eric Biggers
     

08 Oct, 2020

2 commits

  • The sm2 code was split out of public_key.c in a way that breaks
    modular builds. This patch moves the code back into the same file
    as the original motivation was to minimise ifdefs and that has
    nothing to do with splitting the code out.

    Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3...")
    Reported-by: kernel test robot
    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • When memory allocation fails, an appropriate return value
    should be set.

    Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
    Signed-off-by: Tianjia Zhang
    Signed-off-by: Herbert Xu

    Tianjia Zhang
     

25 Sep, 2020

2 commits

  • The digital certificate format based on SM2 crypto algorithm as
    specified in GM/T 0015-2012. It was published by State Encryption
    Management Bureau, China.

    The method of generating Other User Information is defined as
    ZA=H256(ENTLA || IDA || a || b || xG || yG || xA || yA), it also
    specified in https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02.

    The x509 certificate supports SM2-with-SM3 type certificate
    verification. Because certificate verification requires ZA
    in addition to tbs data, ZA also depends on elliptic curve
    parameters and public key data, so you need to access tbs in sig
    and calculate ZA. Finally calculate the digest of the
    signature and complete the verification work. The calculation
    process of ZA is declared in specifications GM/T 0009-2012
    and GM/T 0003.2-2012.

    Signed-off-by: Tianjia Zhang
    Tested-by: Xufeng Zhang
    Reviewed-by: Gilad Ben-Yossef
    Signed-off-by: Herbert Xu

    Tianjia Zhang
     
  • The digital certificate format based on SM2 crypto algorithm as
    specified in GM/T 0015-2012. It was published by State Encryption
    Management Bureau, China.

    This patch adds the OID object identifier defined by OSCCA. The
    x509 certificate supports SM2-with-SM3 type certificate parsing.
    It uses the standard elliptic curve public key, and the sm2
    algorithm signs the hash generated by sm3.

    Signed-off-by: Tianjia Zhang
    Tested-by: Xufeng Zhang
    Reviewed-by: Vitaly Chikunov
    Signed-off-by: Herbert Xu

    Tianjia Zhang
     

08 Aug, 2020

1 commit

  • As said by Linus:

    A symmetric naming is only helpful if it implies symmetries in use.
    Otherwise it's actively misleading.

    In "kzalloc()", the z is meaningful and an important part of what the
    caller wants.

    In "kzfree()", the z is actively detrimental, because maybe in the
    future we really _might_ want to use that "memfill(0xdeadbeef)" or
    something. The "zero" part of the interface isn't even _relevant_.

    The main reason that kzfree() exists is to clear sensitive information
    that should not be leaked to other future users of the same memory
    objects.

    Rename kzfree() to kfree_sensitive() to follow the example of the recently
    added kvfree_sensitive() and make the intention of the API more explicit.
    In addition, memzero_explicit() is used to clear the memory to make sure
    that it won't get optimized away by the compiler.

    The renaming is done by using the command sequence:

    git grep -w --name-only kzfree |\
    xargs sed -i 's/kzfree/kfree_sensitive/'

    followed by some editing of the kfree_sensitive() kerneldoc and adding
    a kzfree backward compatibility macro in slab.h.

    [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
    [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

    Suggested-by: Joe Perches
    Signed-off-by: Waiman Long
    Signed-off-by: Andrew Morton
    Acked-by: David Howells
    Acked-by: Michal Hocko
    Acked-by: Johannes Weiner
    Cc: Jarkko Sakkinen
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: Joe Perches
    Cc: Matthew Wilcox
    Cc: David Rientjes
    Cc: Dan Carpenter
    Cc: "Jason A . Donenfeld"
    Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
    Signed-off-by: Linus Torvalds

    Waiman Long
     

05 Aug, 2020

1 commit

  • Pull documentation updates from Jonathan Corbet:
    "It's been a busy cycle for documentation - hopefully the busiest for a
    while to come. Changes include:

    - Some new Chinese translations

    - Progress on the battle against double words words and non-HTTPS
    URLs

    - Some block-mq documentation

    - More RST conversions from Mauro. At this point, that task is
    essentially complete, so we shouldn't see this kind of churn again
    for a while. Unless we decide to switch to asciidoc or
    something...:)

    - Lots of typo fixes, warning fixes, and more"

    * tag 'docs-5.9' of git://git.lwn.net/linux: (195 commits)
    scripts/kernel-doc: optionally treat warnings as errors
    docs: ia64: correct typo
    mailmap: add entry for
    doc/zh_CN: add cpu-load Chinese version
    Documentation/admin-guide: tainted-kernels: fix spelling mistake
    MAINTAINERS: adjust kprobes.rst entry to new location
    devices.txt: document rfkill allocation
    PCI: correct flag name
    docs: filesystems: vfs: correct flag name
    docs: filesystems: vfs: correct sync_mode flag names
    docs: path-lookup: markup fixes for emphasis
    docs: path-lookup: more markup fixes
    docs: path-lookup: fix HTML entity mojibake
    CREDITS: Replace HTTP links with HTTPS ones
    docs: process: Add an example for creating a fixes tag
    doc/zh_CN: add Chinese translation prefer section
    doc/zh_CN: add clearing-warn-once Chinese version
    doc/zh_CN: add admin-guide index
    doc:it_IT: process: coding-style.rst: Correct __maybe_unused compiler label
    futex: MAINTAINERS: Re-add selftests directory
    ...

    Linus Torvalds
     

16 Jul, 2020

1 commit


20 Jun, 2020

1 commit

  • This file is almost compatible with ReST. Just minor changes
    were needed:

    - Adjust document and titles markups;
    - Adjust numbered list markups;
    - Add a comments markup for the Contents section;
    - Add markups for literal blocks.

    Acked-by: Jarkko Sakkinen
    Signed-off-by: Mauro Carvalho Chehab
    Link: https://lore.kernel.org/r/c2275ea94e0507a01b020ab66dfa824d8b1c2545.1592203650.git.mchehab+huawei@kernel.org
    Signed-off-by: Jonathan Corbet

    Mauro Carvalho Chehab
     

13 Dec, 2019

1 commit

  • No error code was being set on this error path.

    Cc: stable@vger.kernel.org
    Fixes: ad4b1eb5fb33 ("KEYS: asym_tpm: Implement encryption operation [ver #2]")
    Fixes: c08fed737126 ("KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver #2]")
    Reviewed-by: James Morris
    Signed-off-by: Eric Biggers
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Eric Biggers
     

13 Nov, 2019

3 commits

  • Move existing code to trusted keys subsystem. Also, rename files with
    "tpm" as suffix which provides the underlying implementation.

    Suggested-by: Jarkko Sakkinen
    Signed-off-by: Sumit Garg
    Reviewed-by: Jarkko Sakkinen
    Tested-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Sumit Garg
     
  • Switch to utilize common heap based tpm_buf code for TPM based trusted
    and asymmetric keys rather than using stack based tpm1_buf code. Also,
    remove tpm1_buf code.

    Suggested-by: Jarkko Sakkinen
    Signed-off-by: Sumit Garg
    Reviewed-by: Jerry Snitselaar
    Reviewed-by: Jarkko Sakkinen
    Tested-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Sumit Garg
     
  • Move tpm_buf code to common include/linux/tpm.h header so that it can
    be reused via other subsystems like trusted keys etc.

    Also rename trusted keys and asymmetric keys usage of TPM 1.x buffer
    implementation to tpm1_buf to avoid any compilation errors.

    Suggested-by: Jarkko Sakkinen
    Signed-off-by: Sumit Garg
    Reviewed-by: Jerry Snitselaar
    Reviewed-by: Jarkko Sakkinen
    Tested-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen

    Sumit Garg
     

28 Sep, 2019

1 commit

  • Pull kernel lockdown mode from James Morris:
    "This is the latest iteration of the kernel lockdown patchset, from
    Matthew Garrett, David Howells and others.

    From the original description:

    This patchset introduces an optional kernel lockdown feature,
    intended to strengthen the boundary between UID 0 and the kernel.
    When enabled, various pieces of kernel functionality are restricted.
    Applications that rely on low-level access to either hardware or the
    kernel may cease working as a result - therefore this should not be
    enabled without appropriate evaluation beforehand.

    The majority of mainstream distributions have been carrying variants
    of this patchset for many years now, so there's value in providing a
    doesn't meet every distribution requirement, but gets us much closer
    to not requiring external patches.

    There are two major changes since this was last proposed for mainline:

    - Separating lockdown from EFI secure boot. Background discussion is
    covered here: https://lwn.net/Articles/751061/

    - Implementation as an LSM, with a default stackable lockdown LSM
    module. This allows the lockdown feature to be policy-driven,
    rather than encoding an implicit policy within the mechanism.

    The new locked_down LSM hook is provided to allow LSMs to make a
    policy decision around whether kernel functionality that would allow
    tampering with or examining the runtime state of the kernel should be
    permitted.

    The included lockdown LSM provides an implementation with a simple
    policy intended for general purpose use. This policy provides a coarse
    level of granularity, controllable via the kernel command line:

    lockdown={integrity|confidentiality}

    Enable the kernel lockdown feature. If set to integrity, kernel features
    that allow userland to modify the running kernel are disabled. If set to
    confidentiality, kernel features that allow userland to extract
    confidential information from the kernel are also disabled.

    This may also be controlled via /sys/kernel/security/lockdown and
    overriden by kernel configuration.

    New or existing LSMs may implement finer-grained controls of the
    lockdown features. Refer to the lockdown_reason documentation in
    include/linux/security.h for details.

    The lockdown feature has had signficant design feedback and review
    across many subsystems. This code has been in linux-next for some
    weeks, with a few fixes applied along the way.

    Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf
    when kernel lockdown is in confidentiality mode") is missing a
    Signed-off-by from its author. Matthew responded that he is providing
    this under category (c) of the DCO"

    * 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits)
    kexec: Fix file verification on S390
    security: constify some arrays in lockdown LSM
    lockdown: Print current->comm in restriction messages
    efi: Restrict efivar_ssdt_load when the kernel is locked down
    tracefs: Restrict tracefs when the kernel is locked down
    debugfs: Restrict debugfs when the kernel is locked down
    kexec: Allow kexec_file() with appropriate IMA policy when locked down
    lockdown: Lock down perf when in confidentiality mode
    bpf: Restrict bpf when kernel lockdown is in confidentiality mode
    lockdown: Lock down tracing and perf kprobes when in confidentiality mode
    lockdown: Lock down /proc/kcore
    x86/mmiotrace: Lock down the testmmiotrace module
    lockdown: Lock down module params that specify hardware parameters (eg. ioport)
    lockdown: Lock down TIOCSSERIAL
    lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down
    acpi: Disable ACPI table override if the kernel is locked down
    acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
    ACPI: Limit access to custom_method when the kernel is locked down
    x86/msr: Restrict MSR access when the kernel is locked down
    x86: Lock down IO port access when the kernel is locked down
    ...

    Linus Torvalds
     

20 Aug, 2019

1 commit

  • 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
     

06 Aug, 2019

1 commit

  • IMA will need to access the digest of the PKCS7 message (as calculated by
    the kernel) before the signature is verified, so introduce
    pkcs7_get_digest() for that purpose.

    Also, modify pkcs7_digest() to detect when the digest was already
    calculated so that it doesn't have to do redundant work. Verifying that
    sinfo->sig->digest isn't NULL is sufficient because both places which
    allocate sinfo->sig (pkcs7_parse_message() and pkcs7_note_signed_info())
    use kzalloc() so sig->digest is always initialized to zero.

    Signed-off-by: Thiago Jung Bauermann
    Reviewed-by: Mimi Zohar
    Cc: David Howells
    Cc: David Woodhouse
    Cc: Herbert Xu
    Cc: "David S. Miller"
    Signed-off-by: Mimi Zohar

    Thiago Jung Bauermann
     

09 Jul, 2019

2 commits

  • Pull crypto updates from Herbert Xu:
    "Here is the crypto update for 5.3:

    API:
    - Test shash interface directly in testmgr
    - cra_driver_name is now mandatory

    Algorithms:
    - Replace arc4 crypto_cipher with library helper
    - Implement 5 way interleave for ECB, CBC and CTR on arm64
    - Add xxhash
    - Add continuous self-test on noise source to drbg
    - Update jitter RNG

    Drivers:
    - Add support for SHA204A random number generator
    - Add support for 7211 in iproc-rng200
    - Fix fuzz test failures in inside-secure
    - Fix fuzz test failures in talitos
    - Fix fuzz test failures in qat"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits)
    crypto: stm32/hash - remove interruptible condition for dma
    crypto: stm32/hash - Fix hmac issue more than 256 bytes
    crypto: stm32/crc32 - rename driver file
    crypto: amcc - remove memset after dma_alloc_coherent
    crypto: ccp - Switch to SPDX license identifiers
    crypto: ccp - Validate the the error value used to index error messages
    crypto: doc - Fix formatting of new crypto engine content
    crypto: doc - Add parameter documentation
    crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR
    crypto: arm64/aes-ce - add 5 way interleave routines
    crypto: talitos - drop icv_ool
    crypto: talitos - fix hash on SEC1.
    crypto: talitos - move struct talitos_edesc into talitos.h
    lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
    crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
    crypto: asymmetric_keys - select CRYPTO_HASH where needed
    crypto: serpent - mark __serpent_setkey_sbox noinline
    crypto: testmgr - dynamically allocate crypto_shash
    crypto: testmgr - dynamically allocate testvec_config
    crypto: talitos - eliminate unneeded 'done' functions at build time
    ...

    Linus Torvalds
     
  • …/git/dhowells/linux-fs

    Pull keyring namespacing from David Howells:
    "These patches help make keys and keyrings more namespace aware.

    Firstly some miscellaneous patches to make the process easier:

    - Simplify key index_key handling so that the word-sized chunks
    assoc_array requires don't have to be shifted about, making it
    easier to add more bits into the key.

    - Cache the hash value in the key so that we don't have to calculate
    on every key we examine during a search (it involves a bunch of
    multiplications).

    - Allow keying_search() to search non-recursively.

    Then the main patches:

    - Make it so that keyring names are per-user_namespace from the point
    of view of KEYCTL_JOIN_SESSION_KEYRING so that they're not
    accessible cross-user_namespace.

    keyctl_capabilities() shows KEYCTL_CAPS1_NS_KEYRING_NAME for this.

    - Move the user and user-session keyrings to the user_namespace
    rather than the user_struct. This prevents them propagating
    directly across user_namespaces boundaries (ie. the KEY_SPEC_*
    flags will only pick from the current user_namespace).

    - Make it possible to include the target namespace in which the key
    shall operate in the index_key. This will allow the possibility of
    multiple keys with the same description, but different target
    domains to be held in the same keyring.

    keyctl_capabilities() shows KEYCTL_CAPS1_NS_KEY_TAG for this.

    - Make it so that keys are implicitly invalidated by removal of a
    domain tag, causing them to be garbage collected.

    - Institute a network namespace domain tag that allows keys to be
    differentiated by the network namespace in which they operate. New
    keys that are of a type marked 'KEY_TYPE_NET_DOMAIN' are assigned
    the network domain in force when they are created.

    - Make it so that the desired network namespace can be handed down
    into the request_key() mechanism. This allows AFS, NFS, etc. to
    request keys specific to the network namespace of the superblock.

    This also means that the keys in the DNS record cache are
    thenceforth namespaced, provided network filesystems pass the
    appropriate network namespace down into dns_query().

    For DNS, AFS and NFS are good, whilst CIFS and Ceph are not. Other
    cache keyrings, such as idmapper keyrings, also need to set the
    domain tag - for which they need access to the network namespace of
    the superblock"

    * tag 'keys-namespace-20190627' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Pass the network namespace into request_key mechanism
    keys: Network namespace domain tag
    keys: Garbage collect keys for which the domain has been removed
    keys: Include target namespace in match criteria
    keys: Move the user and user-session keyrings to the user_namespace
    keys: Namespace keyring names
    keys: Add a 'recurse' flag for keyring searches
    keys: Cache the hash value to avoid lots of recalculation
    keys: Simplify key description management

    Linus Torvalds
     

27 Jun, 2019

2 commits

  • Build testing with some core crypto options disabled revealed
    a few modules that are missing CRYPTO_HASH:

    crypto/asymmetric_keys/x509_public_key.o: In function `x509_get_sig_params':
    x509_public_key.c:(.text+0x4c7): undefined reference to `crypto_alloc_shash'
    x509_public_key.c:(.text+0x5e5): undefined reference to `crypto_shash_digest'
    crypto/asymmetric_keys/pkcs7_verify.o: In function `pkcs7_digest.isra.0':
    pkcs7_verify.c:(.text+0xab): undefined reference to `crypto_alloc_shash'
    pkcs7_verify.c:(.text+0x1b2): undefined reference to `crypto_shash_digest'
    pkcs7_verify.c:(.text+0x3c1): undefined reference to `crypto_shash_update'
    pkcs7_verify.c:(.text+0x411): undefined reference to `crypto_shash_finup'

    This normally doesn't show up in randconfig tests because there is
    a large number of other options that select CRYPTO_HASH.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Herbert Xu

    Arnd Bergmann
     
  • Add a 'recurse' flag for keyring searches so that the flag can be omitted
    and recursion disabled, thereby allowing just the nominated keyring to be
    searched and none of the children.

    Signed-off-by: David Howells

    David Howells
     

24 May, 2019

1 commit

  • 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

  • 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
     

18 Apr, 2019

3 commits

  • Add Elliptic Curve Russian Digital Signature Algorithm (GOST R
    34.10-2012, RFC 7091, ISO/IEC 14888-3) is one of the Russian (and since
    2018 the CIS countries) cryptographic standard algorithms (called GOST
    algorithms). Only signature verification is supported, with intent to be
    used in the IMA.

    Summary of the changes:

    * crypto/Kconfig:
    - EC-RDSA is added into Public-key cryptography section.

    * crypto/Makefile:
    - ecrdsa objects are added.

    * crypto/asymmetric_keys/x509_cert_parser.c:
    - Recognize EC-RDSA and Streebog OIDs.

    * include/linux/oid_registry.h:
    - EC-RDSA OIDs are added to the enum. Also, a two currently not
    implemented curve OIDs are added for possible extension later (to
    not change numbering and grouping).

    * crypto/ecc.c:
    - Kenneth MacKay copyright date is updated to 2014, because
    vli_mmod_slow, ecc_point_add, ecc_point_mult_shamir are based on his
    code from micro-ecc.
    - Functions needed for ecrdsa are EXPORT_SYMBOL'ed.
    - New functions:
    vli_is_negative - helper to determine sign of vli;
    vli_from_be64 - unpack big-endian array into vli (used for
    a signature);
    vli_from_le64 - unpack little-endian array into vli (used for
    a public key);
    vli_uadd, vli_usub - add/sub u64 value to/from vli (used for
    increment/decrement);
    mul_64_64 - optimized to use __int128 where appropriate, this speeds
    up point multiplication (and as a consequence signature
    verification) by the factor of 1.5-2;
    vli_umult - multiply vli by a small value (speeds up point
    multiplication by another factor of 1.5-2, depending on vli sizes);
    vli_mmod_special - module reduction for some form of Pseudo-Mersenne
    primes (used for the curves A);
    vli_mmod_special2 - module reduction for another form of
    Pseudo-Mersenne primes (used for the curves B);
    vli_mmod_barrett - module reduction using pre-computed value (used
    for the curve C);
    vli_mmod_slow - more general module reduction which is much slower
    (used when the modulus is subgroup order);
    vli_mod_mult_slow - modular multiplication;
    ecc_point_add - add two points;
    ecc_point_mult_shamir - add two points multiplied by scalars in one
    combined multiplication (this gives speed up by another factor 2 in
    compare to two separate multiplications).
    ecc_is_pubkey_valid_partial - additional samity check is added.
    - Updated vli_mmod_fast with non-strict heuristic to call optimal
    module reduction function depending on the prime value;
    - All computations for the previously defined (two NIST) curves should
    not unaffected.

    * crypto/ecc.h:
    - Newly exported functions are documented.

    * crypto/ecrdsa_defs.h
    - Five curves are defined.

    * crypto/ecrdsa.c:
    - Signature verification is implemented.

    * crypto/ecrdsa_params.asn1, crypto/ecrdsa_pub_key.asn1:
    - Templates for BER decoder for EC-RDSA parameters and public key.

    Cc: linux-integrity@vger.kernel.org
    Signed-off-by: Vitaly Chikunov
    Signed-off-by: Herbert Xu

    Vitaly Chikunov
     
  • Some public key algorithms (like EC-DSA) keep in parameters field
    important data such as digest and curve OIDs (possibly more for
    different EC-DSA variants). Thus, just setting a public key (as
    for RSA) is not enough.

    Append parameters into the key stream for akcipher_set_{pub,priv}_key.
    Appended data is: (u32) algo OID, (u32) parameters length, parameters
    data.

    This does not affect current akcipher API nor RSA ciphers (they could
    ignore it). Idea of appending parameters to the key stream is by Herbert
    Xu.

    Cc: David Howells
    Cc: Denis Kenzior
    Cc: keyrings@vger.kernel.org
    Signed-off-by: Vitaly Chikunov
    Reviewed-by: Denis Kenzior
    Signed-off-by: Herbert Xu

    Vitaly Chikunov
     
  • Treat (struct public_key_signature)'s digest same as its signature (s).
    Since digest should be already in the kmalloc'd memory do not kmemdup
    digest value before calling {public,tpm}_key_verify_signature.

    Patch is split from the previous as suggested by Herbert Xu.

    Suggested-by: David Howells
    Cc: David Howells
    Cc: keyrings@vger.kernel.org
    Signed-off-by: Vitaly Chikunov
    Reviewed-by: Denis Kenzior
    Signed-off-by: Herbert Xu

    Vitaly Chikunov