25 Nov, 2019

1 commit


28 Sep, 2019

1 commit

  • Pull integrity updates from Mimi Zohar:
    "The major feature in this time is IMA support for measuring and
    appraising appended file signatures. In addition are a couple of bug
    fixes and code cleanup to use struct_size().

    In addition to the PE/COFF and IMA xattr signatures, the kexec kernel
    image may be signed with an appended signature, using the same
    scripts/sign-file tool that is used to sign kernel modules.

    Similarly, the initramfs may contain an appended signature.

    This contained a lot of refactoring of the existing appended signature
    verification code, so that IMA could retain the existing framework of
    calculating the file hash once, storing it in the IMA measurement list
    and extending the TPM, verifying the file's integrity based on a file
    hash or signature (eg. xattrs), and adding an audit record containing
    the file hash, all based on policy. (The IMA support for appended
    signatures patch set was posted and reviewed 11 times.)

    The support for appended signature paves the way for adding other
    signature verification methods, such as fs-verity, based on a single
    system-wide policy. The file hash used for verifying the signature and
    the signature, itself, can be included in the IMA measurement list"

    * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
    ima: ima_api: Use struct_size() in kzalloc()
    ima: use struct_size() in kzalloc()
    sefltest/ima: support appended signatures (modsig)
    ima: Fix use after free in ima_read_modsig()
    MODSIGN: make new include file self contained
    ima: fix freeing ongoing ahash_request
    ima: always return negative code for error
    ima: Store the measurement again when appraising a modsig
    ima: Define ima-modsig template
    ima: Collect modsig
    ima: Implement support for module-style appended signatures
    ima: Factor xattr_verify() out of ima_appraise_measurement()
    ima: Add modsig appraise_type option for module-style appended signatures
    integrity: Select CONFIG_KEYS instead of depending on it
    PKCS#7: Introduce pkcs7_get_digest()
    PKCS#7: Refactor verify_pkcs7_signature()
    MODSIGN: Export module signature definitions
    ima: initialize the "template" field with the default template

    Linus Torvalds
     

18 Sep, 2019

1 commit

  • Pull documentation updates from Jonathan Corbet:
    "It's a somewhat calmer cycle for docs this time, as the churn of the
    mass RST conversion is happily mostly behind us.

    - A new document on reproducible builds.

    - We finally got around to zapping the documentation for hardware
    support that was removed in 2004; one doesn't want to rush these
    things.

    - The usual assortment of fixes, typo corrections, etc"

    * tag 'docs-5.4' of git://git.lwn.net/linux: (67 commits)
    Documentation: kbuild: Add document about reproducible builds
    docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]
    Documentation: Add "earlycon=sbi" to the admin guide
    doc:lock: remove reference to clever use of read-write lock
    devices.txt: improve entry for comedi (char major 98)
    docs: mtd: Update spi nor reference driver
    doc: arm64: fix grammar dtb placed in no attributes region
    Documentation: sysrq: don't recommend 'S' 'U' before 'B'
    mailmap: Update email address for Quentin Perret
    docs: ftrace: clarify when tracing is disabled by the trace file
    docs: process: fix broken link
    Documentation/arm/samsung-s3c24xx: Remove stray U+FEFF character to fix title
    Documentation/arm/sa1100/assabet: Fix 'make assabet_defconfig' command
    Documentation/arm/sa1100: Remove some obsolete documentation
    docs/zh_CN: update Chinese howto.rst for latexdocs making
    Documentation: virt: Fix broken reference to virt tree's index
    docs: Fix typo on pull requests guide
    kernel-doc: Allow anonymous enum
    Documentation: sphinx: Don't parse socket() as identifier reference
    Documentation: sphinx: Add missing comma to list of strings
    ...

    Linus Torvalds
     

02 Sep, 2019

1 commit


06 Aug, 2019

1 commit

  • Define new "d-modsig" template field which holds the digest that is
    expected to match the one contained in the modsig, and also new "modsig"
    template field which holds the appended file signature.

    Add a new "ima-modsig" defined template descriptor with the new fields as
    well as the ones from the "ima-sig" descriptor.

    Change ima_store_measurement() to accept a struct modsig * argument so that
    it can be passed along to the templates via struct ima_event_data.

    Suggested-by: Mimi Zohar
    Signed-off-by: Thiago Jung Bauermann
    Signed-off-by: Mimi Zohar

    Thiago Jung Bauermann
     

01 Aug, 2019

1 commit


15 Jul, 2019

2 commits


11 Jul, 2019

1 commit

  • …el/git/dhowells/linux-fs"

    This reverts merge 0f75ef6a9cff49ff612f7ce0578bced9d0b38325 (and thus
    effectively commits

    7a1ade847596 ("keys: Provide KEYCTL_GRANT_PERMISSION")
    2e12256b9a76 ("keys: Replace uid/gid/perm permissions checking with an ACL")

    that the merge brought in).

    It turns out that it breaks booting with an encrypted volume, and Eric
    biggers reports that it also breaks the fscrypt tests [1] and loading of
    in-kernel X.509 certificates [2].

    The root cause of all the breakage is likely the same, but David Howells
    is off email so rather than try to work it out it's getting reverted in
    order to not impact the rest of the merge window.

    [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/
    [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/

    Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/
    Reported-by: Eric Biggers <ebiggers@kernel.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: James Morris <jmorris@namei.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Linus Torvalds
     

10 Jul, 2019

1 commit

  • Pull Documentation updates from Jonathan Corbet:
    "It's been a relatively busy cycle for docs:

    - A fair pile of RST conversions, many from Mauro. These create more
    than the usual number of simple but annoying merge conflicts with
    other trees, unfortunately. He has a lot more of these waiting on
    the wings that, I think, will go to you directly later on.

    - A new document on how to use merges and rebases in kernel repos,
    and one on Spectre vulnerabilities.

    - Various improvements to the build system, including automatic
    markup of function() references because some people, for reasons I
    will never understand, were of the opinion that
    :c:func:``function()`` is unattractive and not fun to type.

    - We now recommend using sphinx 1.7, but still support back to 1.4.

    - Lots of smaller improvements, warning fixes, typo fixes, etc"

    * tag 'docs-5.3' of git://git.lwn.net/linux: (129 commits)
    docs: automarkup.py: ignore exceptions when seeking for xrefs
    docs: Move binderfs to admin-guide
    Disable Sphinx SmartyPants in HTML output
    doc: RCU callback locks need only _bh, not necessarily _irq
    docs: format kernel-parameters -- as code
    Doc : doc-guide : Fix a typo
    platform: x86: get rid of a non-existent document
    Add the RCU docs to the core-api manual
    Documentation: RCU: Add TOC tree hooks
    Documentation: RCU: Rename txt files to rst
    Documentation: RCU: Convert RCU UP systems to reST
    Documentation: RCU: Convert RCU linked list to reST
    Documentation: RCU: Convert RCU basic concepts to reST
    docs: filesystems: Remove uneeded .rst extension on toctables
    scripts/sphinx-pre-install: fix out-of-tree build
    docs: zh_CN: submitting-drivers.rst: Remove a duplicated Documentation/
    Documentation: PGP: update for newer HW devices
    Documentation: Add section about CPU vulnerabilities for Spectre
    Documentation: platform: Delete x86-laptop-drivers.txt
    docs: Note that :c:func: should no longer be used
    ...

    Linus Torvalds
     

09 Jul, 2019

1 commit

  • Pull integrity updates from Mimi Zohar:
    "Bug fixes, code clean up, and new features:

    - IMA policy rules can be defined in terms of LSM labels, making the
    IMA policy dependent on LSM policy label changes, in particular LSM
    label deletions. The new environment, in which IMA-appraisal is
    being used, frequently updates the LSM policy and permits LSM label
    deletions.

    - Prevent an mmap'ed shared file opened for write from also being
    mmap'ed execute. In the long term, making this and other similar
    changes at the VFS layer would be preferable.

    - The IMA per policy rule template format support is needed for a
    couple of new/proposed features (eg. kexec boot command line
    measurement, appended signatures, and VFS provided file hashes).

    - Other than the "boot-aggregate" record in the IMA measuremeent
    list, all other measurements are of file data. Measuring and
    storing the kexec boot command line in the IMA measurement list is
    the first buffer based measurement included in the measurement
    list"

    * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
    integrity: Introduce struct evm_xattr
    ima: Update MAX_TEMPLATE_NAME_LEN to fit largest reasonable definition
    KEXEC: Call ima_kexec_cmdline to measure the boot command line args
    IMA: Define a new template field buf
    IMA: Define a new hook to measure the kexec boot command line arguments
    IMA: support for per policy rule template formats
    integrity: Fix __integrity_init_keyring() section mismatch
    ima: Use designated initializers for struct ima_event_data
    ima: use the lsm policy update notifier
    LSM: switch to blocking policy update notifiers
    x86/ima: fix the Kconfig dependency for IMA_ARCH_POLICY
    ima: Make arch_policy_entry static
    ima: prevent a file already mmap'ed write to be mmap'ed execute
    x86/ima: check EFI SetupMode too

    Linus Torvalds
     

01 Jul, 2019

1 commit

  • A buffer(kexec boot command line arguments) measured into IMA
    measuremnt list cannot be appraised, without already being
    aware of the buffer contents. Since hashes are non-reversible,
    raw buffer is needed for validation or regenerating hash for
    appraisal/attestation.

    Add support to store/read the buffer contents in HEX.
    The kexec cmdline hash is stored in the "d-ng" field of the
    template data. It can be verified using
    sudo cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements |
    grep kexec-cmdline | cut -d' ' -f 6 | xxd -r -p | sha256sum

    - Add two new fields to ima_event_data to hold the buf and
    buf_len
    - Add a new template field 'buf' to be used to store/read
    the buffer data.
    - Updated process_buffer_meaurement to add the buffer to
    ima_event_data. process_buffer_measurement added in
    "Define a new IMA hook to measure the boot command line
    arguments"
    - Add a new template policy name ima-buf to represent
    'd-ng|n-ng|buf'

    Signed-off-by: Prakhar Srivastava
    Reviewed-by: Roberto Sassu
    Reviewed-by: James Morris
    Signed-off-by: Mimi Zohar

    Prakhar Srivastava
     

28 Jun, 2019

2 commits

  • Replace the uid/gid/perm permissions checking on a key with an ACL to allow
    the SETATTR and SEARCH permissions to be split. This will also allow a
    greater range of subjects to represented.

    ============
    WHY DO THIS?
    ============

    The problem is that SETATTR and SEARCH cover a slew of actions, not all of
    which should be grouped together.

    For SETATTR, this includes actions that are about controlling access to a
    key:

    (1) Changing a key's ownership.

    (2) Changing a key's security information.

    (3) Setting a keyring's restriction.

    And actions that are about managing a key's lifetime:

    (4) Setting an expiry time.

    (5) Revoking a key.

    and (proposed) managing a key as part of a cache:

    (6) Invalidating a key.

    Managing a key's lifetime doesn't really have anything to do with
    controlling access to that key.

    Expiry time is awkward since it's more about the lifetime of the content
    and so, in some ways goes better with WRITE permission. It can, however,
    be set unconditionally by a process with an appropriate authorisation token
    for instantiating a key, and can also be set by the key type driver when a
    key is instantiated, so lumping it with the access-controlling actions is
    probably okay.

    As for SEARCH permission, that currently covers:

    (1) Finding keys in a keyring tree during a search.

    (2) Permitting keyrings to be joined.

    (3) Invalidation.

    But these don't really belong together either, since these actions really
    need to be controlled separately.

    Finally, there are number of special cases to do with granting the
    administrator special rights to invalidate or clear keys that I would like
    to handle with the ACL rather than key flags and special checks.

    ===============
    WHAT IS CHANGED
    ===============

    The SETATTR permission is split to create two new permissions:

    (1) SET_SECURITY - which allows the key's owner, group and ACL to be
    changed and a restriction to be placed on a keyring.

    (2) REVOKE - which allows a key to be revoked.

    The SEARCH permission is split to create:

    (1) SEARCH - which allows a keyring to be search and a key to be found.

    (2) JOIN - which allows a keyring to be joined as a session keyring.

    (3) INVAL - which allows a key to be invalidated.

    The WRITE permission is also split to create:

    (1) WRITE - which allows a key's content to be altered and links to be
    added, removed and replaced in a keyring.

    (2) CLEAR - which allows a keyring to be cleared completely. This is
    split out to make it possible to give just this to an administrator.

    (3) REVOKE - see above.

    Keys acquire ACLs which consist of a series of ACEs, and all that apply are
    unioned together. An ACE specifies a subject, such as:

    (*) Possessor - permitted to anyone who 'possesses' a key
    (*) Owner - permitted to the key owner
    (*) Group - permitted to the key group
    (*) Everyone - permitted to everyone

    Note that 'Other' has been replaced with 'Everyone' on the assumption that
    you wouldn't grant a permit to 'Other' that you wouldn't also grant to
    everyone else.

    Further subjects may be made available by later patches.

    The ACE also specifies a permissions mask. The set of permissions is now:

    VIEW Can view the key metadata
    READ Can read the key content
    WRITE Can update/modify the key content
    SEARCH Can find the key by searching/requesting
    LINK Can make a link to the key
    SET_SECURITY Can change owner, ACL, expiry
    INVAL Can invalidate
    REVOKE Can revoke
    JOIN Can join this keyring
    CLEAR Can clear this keyring

    The KEYCTL_SETPERM function is then deprecated.

    The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
    or if the caller has a valid instantiation auth token.

    The KEYCTL_INVALIDATE function then requires INVAL.

    The KEYCTL_REVOKE function then requires REVOKE.

    The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
    existing keyring.

    The JOIN permission is enabled by default for session keyrings and manually
    created keyrings only.

    ======================
    BACKWARD COMPATIBILITY
    ======================

    To maintain backward compatibility, KEYCTL_SETPERM will translate the
    permissions mask it is given into a new ACL for a key - unless
    KEYCTL_SET_ACL has been called on that key, in which case an error will be
    returned.

    It will convert possessor, owner, group and other permissions into separate
    ACEs, if each portion of the mask is non-zero.

    SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE
    permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned
    on if a keyring is being altered.

    The KEYCTL_DESCRIBE function translates the ACL back into a permissions
    mask to return depending on possessor, owner, group and everyone ACEs.

    It will make the following mappings:

    (1) INVAL, JOIN -> SEARCH

    (2) SET_SECURITY -> SETATTR

    (3) REVOKE -> WRITE if SETATTR isn't already set

    (4) CLEAR -> WRITE

    Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
    the value set with KEYCTL_SETATTR.

    =======
    TESTING
    =======

    This passes the keyutils testsuite for all but a couple of tests:

    (1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
    returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
    if the type doesn't have ->read(). You still can't actually read the
    key.

    (2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
    work as Other has been replaced with Everyone in the ACL.

    Signed-off-by: David Howells

    David Howells
     
  • Create a request_key_net() function and use it to pass the network
    namespace domain tag into DNS revolver keys and rxrpc/AFS keys so that keys
    for different domains can coexist in the same keyring.

    Signed-off-by: David Howells
    cc: netdev@vger.kernel.org
    cc: linux-nfs@vger.kernel.org
    cc: linux-cifs@vger.kernel.org
    cc: linux-afs@lists.infradead.org

    David Howells
     

27 Jun, 2019

2 commits


19 Jun, 2019

4 commits

  • If a filesystem uses keys to hold authentication tokens, then it needs a
    token for each VFS operation that might perform an authentication check -
    either by passing it to the server, or using to perform a check based on
    authentication data cached locally.

    For open files this isn't a problem, since the key should be cached in the
    file struct since it represents the subject performing operations on that
    file descriptor.

    During pathwalk, however, there isn't anywhere to cache the key, except
    perhaps in the nameidata struct - but that isn't exposed to the
    filesystems. Further, a pathwalk can incur a lot of operations, calling
    one or more of the following, for instance:

    ->lookup()
    ->permission()
    ->d_revalidate()
    ->d_automount()
    ->get_acl()
    ->getxattr()

    on each dentry/inode it encounters - and each one may need to call
    request_key(). And then, at the end of pathwalk, it will call the actual
    operation:

    ->mkdir()
    ->mknod()
    ->getattr()
    ->open()
    ...

    which may need to go and get the token again.

    However, it is very likely that all of the operations on a single
    dentry/inode - and quite possibly a sequence of them - will all want to use
    the same authentication token, which suggests that caching it would be a
    good idea.

    To this end:

    (1) Make it so that a positive result of request_key() and co. that didn't
    require upcalling to userspace is cached temporarily in task_struct.

    (2) The cache is 1 deep, so a new result displaces the old one.

    (3) The key is released by exit and by notify-resume.

    (4) The cache is cleared in a newly forked process.

    Signed-off-by: David Howells

    David Howells
     
  • Provide a request_key_rcu() function that can be used to request a key
    under RCU conditions. It can only search and check permissions; it cannot
    allocate a new key, upcall or wait for an upcall to complete. It may
    return a partially constructed key.

    Signed-off-by: David Howells

    David Howells
     
  • Move the RCU locks outwards from the keyring search functions so that it
    will become possible to provide an RCU-capable partial request_key()
    function in a later commit.

    Signed-off-by: David Howells

    David Howells
     
  • The request_key() syscall allows a process to gain access to the 'possessor'
    permits of any key that grants it Search permission by virtue of request_key()
    not checking whether a key it finds grants Link permission to the caller.

    Signed-off-by: David Howells

    David Howells
     

09 Jun, 2019

2 commits

  • Multi-line literal markups only work when they're idented at the
    same level, with is not the case here:

    Documentation/security/keys/core.rst:1597: WARNING: Inline literal start-string without end-string.
    Documentation/security/keys/core.rst:1597: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1597: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1598: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1598: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1600: WARNING: Inline literal start-string without end-string.
    Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1600: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1666: WARNING: Inline literal start-string without end-string.
    Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.
    Documentation/security/keys/core.rst:1666: WARNING: Inline emphasis start-string without end-string.

    Fix it by using a code-block instead.

    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Jonathan Corbet

    Mauro Carvalho Chehab
     
  • The code-block tag is at the wrong place, causing those
    warnings:

    Documentation/security/keys/trusted-encrypted.rst:112: WARNING: Literal block expected; none found.
    Documentation/security/keys/trusted-encrypted.rst:121: WARNING: Unexpected indentation.
    Documentation/security/keys/trusted-encrypted.rst:122: WARNING: Block quote ends without a blank line; unexpected unindent.
    Documentation/security/keys/trusted-encrypted.rst:123: WARNING: Block quote ends without a blank line; unexpected unindent.

    Signed-off-by: Mauro Carvalho Chehab
    Acked-by: James Morris
    Acked-by: Jarkko Sakkinen
    Signed-off-by: Jonathan Corbet

    Mauro Carvalho Chehab
     

31 May, 2019

1 commit

  • Add a keyctl to atomically move a link to a key from one keyring to
    another. The key must exist in "from" keyring and a flag can be given to
    cause the operation to fail if there's a matching key already in the "to"
    keyring.

    This can be done with:

    keyctl(KEYCTL_MOVE,
    key_serial_t key,
    key_serial_t from_keyring,
    key_serial_t to_keyring,
    unsigned int flags);

    The key being moved must grant Link permission and both keyrings must grant
    Write permission.

    flags should be 0 or KEYCTL_MOVE_EXCL, with the latter preventing
    displacement of a matching key from the "to" keyring.

    Signed-off-by: David Howells

    David Howells
     

22 Feb, 2019

2 commits

  • There is a lot of kern-doc for the LSM internals, but it wasn't visible
    in the HTML output. This exposes some formatting flaws in lsm_hooks.h
    that will be fixed in a later series of patches.

    Signed-off-by: Kees Cook
    Signed-off-by: Jonathan Corbet

    Kees Cook
     
  • The SCTP sections were ending up at the top-level table of contents
    under the security section when they should have be sections with the
    SCTP chapters. In addition to correcting the section and subsection
    headings, this merges the SCTP documents into a single file to organize
    the chapters more clearly, internally linkifies them, and adds the
    missing SPDX header.

    Signed-off-by: Kees Cook
    Acked-by: Paul Moore
    Signed-off-by: Jonathan Corbet

    Kees Cook
     

03 Jan, 2019

1 commit

  • …morris/linux-security

    Pull integrity updates from James Morris:
    "In Linux 4.19, a new LSM hook named security_kernel_load_data was
    upstreamed, allowing LSMs and IMA to prevent the kexec_load syscall.
    Different signature verification methods exist for verifying the
    kexec'ed kernel image. This adds additional support in IMA to prevent
    loading unsigned kernel images via the kexec_load syscall,
    independently of the IMA policy rules, based on the runtime "secure
    boot" flag. An initial IMA kselftest is included.

    In addition, this pull request defines a new, separate keyring named
    ".platform" for storing the preboot/firmware keys needed for verifying
    the kexec'ed kernel image's signature and includes the associated IMA
    kexec usage of the ".platform" keyring.

    (David Howell's and Josh Boyer's patches for reading the
    preboot/firmware keys, which were previously posted for a different
    use case scenario, are included here)"

    * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
    integrity: Remove references to module keyring
    ima: Use inode_is_open_for_write
    ima: Support platform keyring for kernel appraisal
    efi: Allow the "db" UEFI variable to be suppressed
    efi: Import certificates from UEFI Secure Boot
    efi: Add an EFI signature blob parser
    efi: Add EFI signature data types
    integrity: Load certs to the platform keyring
    integrity: Define a trusted platform keyring
    selftests/ima: kexec_load syscall test
    ima: don't measure/appraise files on efivarfs
    x86/ima: retry detecting secure boot mode
    docs: Extend trusted keys documentation for TPM 2.0
    x86/ima: define arch_get_ima_policy() for x86
    ima: add support for arch specific policies
    ima: refactor ima_init_policy()
    ima: prevent kexec_load syscall based on runtime secureboot flag
    x86/ima: define arch_ima_get_secureboot
    integrity: support new struct public_key_signature encoding field

    Linus Torvalds
     

30 Dec, 2018

1 commit

  • Pull documentation update from Jonathan Corbet:
    "A fairly normal cycle for documentation stuff. We have a new document
    on perf security, more Italian translations, more improvements to the
    memory-management docs, improvements to the pathname lookup
    documentation, and the usual array of smaller fixes.

    As is often the case, there are a few reaches outside of
    Documentation/ to adjust kerneldoc comments"

    * tag 'docs-5.0' of git://git.lwn.net/linux: (38 commits)
    docs: improve pathname-lookup document structure
    configfs: fix wrong name of struct in documentation
    docs/mm-api: link slab_common.c to "The Slab Cache" section
    slab: make kmem_cache_create{_usercopy} description proper kernel-doc
    doc:process: add links where missing
    docs/core-api: make mm-api.rst more structured
    x86, boot: documentation whitespace fixup
    Documentation: devres: note checking needs when converting
    doc:it: add some process/* translations
    doc:it: fixes in process/1.Intro
    Documentation: convert path-lookup from markdown to resturctured text
    Documentation/admin-guide: update admin-guide index.rst
    Documentation/admin-guide: introduce perf-security.rst file
    scripts/kernel-doc: Fix struct and struct field attribute processing
    Documentation: dev-tools: Fix typos in index.rst
    Correct gen_init_cpio tool's documentation
    Document /proc/pid PID reuse behavior
    Documentation: update path-lookup.md for parallel lookups
    Documentation: Use "while" instead of "whilst"
    dmaengine: Add mailing list address to the documentation
    ...

    Linus Torvalds
     

14 Dec, 2018

1 commit


11 Dec, 2018

1 commit

  • Extend the documentation for trusted keys with documentation for how to
    set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well.

    Signed-off-by: Stefan Berger
    Reviewed-by: Mimi Zohar
    Reviewed-by: Dave Jiang
    Acked-by: Dan Williams
    Acked-by: Jerry Snitselaar
    Signed-off-by: Mimi Zohar

    Stefan Berger
     

21 Nov, 2018

1 commit

  • Whilst making an unrelated change to some Documentation, Linus sayeth:

    | Afaik, even in Britain, "whilst" is unusual and considered more
    | formal, and "while" is the common word.
    |
    | [...]
    |
    | Can we just admit that we work with computers, and we don't need to
    | use þe eald Englisc spelling of words that most of the world never
    | uses?

    dictionary.com refers to the word as "Chiefly British", which is
    probably an undesirable attribute for technical documentation.

    Replace all occurrences under Documentation/ with "while".

    Cc: David Howells
    Cc: Liam Girdwood
    Cc: Chris Wilson
    Cc: Michael Halcrow
    Cc: Jonathan Corbet
    Reported-by: Linus Torvalds
    Signed-off-by: Will Deacon
    Signed-off-by: Jonathan Corbet

    Will Deacon
     

02 Nov, 2018

2 commits

  • Pull keys updates from James Morris:
    "Provide five new operations in the key_type struct that can be used to
    provide access to asymmetric key operations. These will be implemented
    for the asymmetric key type in a later patch and may refer to a key
    retained in RAM by the kernel or a key retained in crypto hardware.

    int (*asym_query)(const struct kernel_pkey_params *params,
    struct kernel_pkey_query *info);
    int (*asym_eds_op)(struct kernel_pkey_params *params,
    const void *in, void *out);
    int (*asym_verify_signature)(struct kernel_pkey_params *params,
    const void *in, const void *in2);

    Since encrypt, decrypt and sign are identical in their interfaces,
    they're rolled together in the asym_eds_op() operation and there's an
    operation ID in the params argument to distinguish them.

    Verify is different in that we supply the data and the signature
    instead and get an error value (or 0) as the only result on the
    expectation that this may well be how a hardware crypto device may
    work"

    * 'next-keys2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (22 commits)
    KEYS: asym_tpm: Add support for the sign operation [ver #2]
    KEYS: asym_tpm: Implement tpm_sign [ver #2]
    KEYS: asym_tpm: Implement signature verification [ver #2]
    KEYS: asym_tpm: Implement the decrypt operation [ver #2]
    KEYS: asym_tpm: Implement tpm_unbind [ver #2]
    KEYS: asym_tpm: Add loadkey2 and flushspecific [ver #2]
    KEYS: Move trusted.h to include/keys [ver #2]
    KEYS: trusted: Expose common functionality [ver #2]
    KEYS: asym_tpm: Implement encryption operation [ver #2]
    KEYS: asym_tpm: Implement pkey_query [ver #2]
    KEYS: Add parser for TPM-based keys [ver #2]
    KEYS: asym_tpm: extract key size & public key [ver #2]
    KEYS: asym_tpm: add skeleton for asym_tpm [ver #2]
    crypto: rsa-pkcs1pad: Allow hash to be optional [ver #2]
    KEYS: Implement PKCS#8 RSA Private Key parser [ver #2]
    KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver #2]
    KEYS: Allow the public_key struct to hold a private key [ver #2]
    KEYS: Provide software public key query function [ver #2]
    KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type [ver #2]
    KEYS: Provide missing asymmetric key subops for new key type ops [ver #2]
    ...

    Linus Torvalds
     
  • Pull stackleak gcc plugin from Kees Cook:
    "Please pull this new GCC plugin, stackleak, for v4.20-rc1. This plugin
    was ported from grsecurity by Alexander Popov. It provides efficient
    stack content poisoning at syscall exit. This creates a defense
    against at least two classes of flaws:

    - Uninitialized stack usage. (We continue to work on improving the
    compiler to do this in other ways: e.g. unconditional zero init was
    proposed to GCC and Clang, and more plugin work has started too).

    - Stack content exposure. By greatly reducing the lifetime of valid
    stack contents, exposures via either direct read bugs or unknown
    cache side-channels become much more difficult to exploit. This
    complements the existing buddy and heap poisoning options, but
    provides the coverage for stacks.

    The x86 hooks are included in this series (which have been reviewed by
    Ingo, Dave Hansen, and Thomas Gleixner). The arm64 hooks have already
    been merged through the arm64 tree (written by Laura Abbott and
    reviewed by Mark Rutland and Will Deacon).

    With VLAs having been removed this release, there is no need for
    alloca() protection, so it has been removed from the plugin"

    * tag 'stackleak-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
    arm64: Drop unneeded stackleak_check_alloca()
    stackleak: Allow runtime disabling of kernel stack erasing
    doc: self-protection: Add information about STACKLEAK feature
    fs/proc: Show STACKLEAK metrics in the /proc file system
    lkdtm: Add a test for STACKLEAK
    gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack
    x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls

    Linus Torvalds
     

26 Oct, 2018

2 commits

  • Provide five keyctl functions that permit userspace to make use of the new
    key type ops for accessing and driving asymmetric keys.

    (*) Query an asymmetric key.

    long keyctl(KEYCTL_PKEY_QUERY,
    key_serial_t key, unsigned long reserved,
    struct keyctl_pkey_query *info);

    Get information about an asymmetric key. The information is returned
    in the keyctl_pkey_query struct:

    __u32 supported_ops;

    A bit mask of flags indicating which ops are supported. This is
    constructed from a bitwise-OR of:

    KEYCTL_SUPPORTS_{ENCRYPT,DECRYPT,SIGN,VERIFY}

    __u32 key_size;

    The size in bits of the key.

    __u16 max_data_size;
    __u16 max_sig_size;
    __u16 max_enc_size;
    __u16 max_dec_size;

    The maximum sizes in bytes of a blob of data to be signed, a signature
    blob, a blob to be encrypted and a blob to be decrypted.

    reserved must be set to 0. This is intended for future use to hand
    over one or more passphrases needed unlock a key.

    If successful, 0 is returned. If the key is not an asymmetric key,
    EOPNOTSUPP is returned.

    (*) Encrypt, decrypt, sign or verify a blob using an asymmetric key.

    long keyctl(KEYCTL_PKEY_ENCRYPT,
    const struct keyctl_pkey_params *params,
    const char *info,
    const void *in,
    void *out);

    long keyctl(KEYCTL_PKEY_DECRYPT,
    const struct keyctl_pkey_params *params,
    const char *info,
    const void *in,
    void *out);

    long keyctl(KEYCTL_PKEY_SIGN,
    const struct keyctl_pkey_params *params,
    const char *info,
    const void *in,
    void *out);

    long keyctl(KEYCTL_PKEY_VERIFY,
    const struct keyctl_pkey_params *params,
    const char *info,
    const void *in,
    const void *in2);

    Use an asymmetric key to perform a public-key cryptographic operation
    a blob of data.

    The parameter block pointed to by params contains a number of integer
    values:

    __s32 key_id;
    __u32 in_len;
    __u32 out_len;
    __u32 in2_len;

    For a given operation, the in and out buffers are used as follows:

    Operation ID in,in_len out,out_len in2,in2_len
    ======================= =============== =============== ===========
    KEYCTL_PKEY_ENCRYPT Raw data Encrypted data -
    KEYCTL_PKEY_DECRYPT Encrypted data Raw data -
    KEYCTL_PKEY_SIGN Raw data Signature -
    KEYCTL_PKEY_VERIFY Raw data - Signature

    info is a string of key=value pairs that supply supplementary
    information.

    The __spare space in the parameter block must be set to 0. This is
    intended, amongst other things, to allow the passing of passphrases
    required to unlock a key.

    If successful, encrypt, decrypt and sign all return the amount of data
    written into the output buffer. Verification returns 0 on success.

    Signed-off-by: David Howells
    Tested-by: Marcel Holtmann
    Reviewed-by: Marcel Holtmann
    Reviewed-by: Denis Kenzior
    Tested-by: Denis Kenzior
    Signed-off-by: James Morris

    David Howells
     
  • Provide five new operations in the key_type struct that can be used to
    provide access to asymmetric key operations. These will be implemented for
    the asymmetric key type in a later patch and may refer to a key retained in
    RAM by the kernel or a key retained in crypto hardware.

    int (*asym_query)(const struct kernel_pkey_params *params,
    struct kernel_pkey_query *info);
    int (*asym_eds_op)(struct kernel_pkey_params *params,
    const void *in, void *out);
    int (*asym_verify_signature)(struct kernel_pkey_params *params,
    const void *in, const void *in2);

    Since encrypt, decrypt and sign are identical in their interfaces, they're
    rolled together in the asym_eds_op() operation and there's an operation ID
    in the params argument to distinguish them.

    Verify is different in that we supply the data and the signature instead
    and get an error value (or 0) as the only result on the expectation that
    this may well be how a hardware crypto device may work.

    Signed-off-by: David Howells
    Tested-by: Marcel Holtmann
    Reviewed-by: Marcel Holtmann
    Reviewed-by: Denis Kenzior
    Tested-by: Denis Kenzior
    Signed-off-by: James Morris

    David Howells
     

25 Oct, 2018

1 commit

  • Pull documentation updates from Jonathan Corbet:
    "This is a fairly typical cycle for documentation. There's some welcome
    readability improvements for the formatted output, some LICENSES
    updates including the addition of the ISC license, the removal of the
    unloved and unmaintained 00-INDEX files, the deprecated APIs document
    from Kees, more MM docs from Mike Rapoport, and the usual pile of typo
    fixes and corrections"

    * tag 'docs-4.20' of git://git.lwn.net/linux: (41 commits)
    docs: Fix typos in histogram.rst
    docs: Introduce deprecated APIs list
    kernel-doc: fix declaration type determination
    doc: fix a typo in adding-syscalls.rst
    docs/admin-guide: memory-hotplug: remove table of contents
    doc: printk-formats: Remove bogus kobject references for device nodes
    Documentation: preempt-locking: Use better example
    dm flakey: Document "error_writes" feature
    docs/completion.txt: Fix a couple of punctuation nits
    LICENSES: Add ISC license text
    LICENSES: Add note to CDDL-1.0 license that it should not be used
    docs/core-api: memory-hotplug: add some details about locking internals
    docs/core-api: rename memory-hotplug-notifier to memory-hotplug
    docs: improve readability for people with poorer eyesight
    yama: clarify ptrace_scope=2 in Yama documentation
    docs/vm: split memory hotplug notifier description to Documentation/core-api
    docs: move memory hotplug description into admin-guide/mm
    doc: Fix acronym "FEKEK" in ecryptfs
    docs: fix some broken documentation references
    iommu: Fix passthrough option documentation
    ...

    Linus Torvalds
     

10 Oct, 2018

1 commit

  • Acked-by: Kees Cook

    Fix Documentation location reference for where LSM descriptions should
    be placed.

    Suggested-by: Kees Cook
    Signed-off-by: Randy Dunlap
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: linux-security-module@vger.kernel.org
    Signed-off-by: James Morris

    Randy Dunlap
     

21 Sep, 2018

1 commit


05 Sep, 2018

1 commit


14 Jun, 2018

1 commit

  • The changes to automatically test for working stack protector compiler
    support in the Kconfig files removed the special STACKPROTECTOR_AUTO
    option that picked the strongest stack protector that the compiler
    supported.

    That was all a nice cleanup - it makes no sense to have the AUTO case
    now that the Kconfig phase can just determine the compiler support
    directly.

    HOWEVER.

    It also meant that doing "make oldconfig" would now _disable_ the strong
    stackprotector if you had AUTO enabled, because in a legacy config file,
    the sane stack protector configuration would look like

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    # CONFIG_CC_STACKPROTECTOR_NONE is not set
    # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
    # CONFIG_CC_STACKPROTECTOR_STRONG is not set
    CONFIG_CC_STACKPROTECTOR_AUTO=y

    and when you ran this through "make oldconfig" with the Kbuild changes,
    it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
    been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
    CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
    used to be disabled (because it was really enabled by AUTO), and would
    disable it in the new config, resulting in:

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
    CONFIG_CC_STACKPROTECTOR=y
    # CONFIG_CC_STACKPROTECTOR_STRONG is not set
    CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

    That's dangerously subtle - people could suddenly find themselves with
    the weaker stack protector setup without even realizing.

    The solution here is to just rename not just the old RECULAR stack
    protector option, but also the strong one. This does that by just
    removing the CC_ prefix entirely for the user choices, because it really
    is not about the compiler support (the compiler support now instead
    automatially impacts _visibility_ of the options to users).

    This results in "make oldconfig" actually asking the user for their
    choice, so that we don't have any silent subtle security model changes.
    The end result would generally look like this:

    CONFIG_HAVE_CC_STACKPROTECTOR=y
    CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
    CONFIG_STACKPROTECTOR=y
    CONFIG_STACKPROTECTOR_STRONG=y
    CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

    where the "CC_" versions really are about internal compiler
    infrastructure, not the user selections.

    Acked-by: Masahiro Yamada
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

08 May, 2018

1 commit