14 Dec, 2020

1 commit

  • Secure keys are derieved using CAAM crypto block.

    Secure keys derieved are the random number symmetric keys from CAAM.
    Blobs corresponding to the key are formed using CAAM. User space
    will only be able to view the blob of the key.

    Signed-off-by: Udit Agarwal

    Reviewed-by: Sahil Malhotra
    [ Aisheng: fix minior conflicts due to
    47f9c2796891 ("KEYS: trusted: Create trusted keys subsystem") ]
    Sign-off-by: Dong Aisheng

    Udit Agarwal
     

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
     

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
     

16 Jun, 2020

2 commits

  • There is a regular need in the kernel to provide a way to declare having a
    dynamically sized set of trailing elements in a structure. Kernel code should
    always use “flexible array members”[1] for these cases. The older style of
    one-element or zero-length arrays should no longer be used[2].

    [1] https://en.wikipedia.org/wiki/Flexible_array_member
    [2] https://github.com/KSPP/linux/issues/21

    Signed-off-by: Gustavo A. R. Silva

    Gustavo A. R. Silva
     
  • There is a regular need in the kernel to provide a way to declare having a
    dynamically sized set of trailing elements in a structure. Kernel code should
    always use “flexible array members”[1] for these cases. The older style of
    one-element or zero-length arrays should no longer be used[2].

    [1] https://en.wikipedia.org/wiki/Flexible_array_member
    [2] https://github.com/KSPP/linux/issues/21

    Signed-off-by: Gustavo A. R. Silva

    Gustavo A. R. Silva
     

03 Jun, 2020

2 commits

  • Implement the ->update op for the big_key type.

    Signed-off-by: David Howells
    Acked-by: Jason A. Donenfeld

    David Howells
     
  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    sizeof(flexible-array-member) triggers a warning because flexible array
    members have incomplete type[1]. There are some instances of code in
    which the sizeof operator is being incorrectly/erroneously applied to
    zero-length arrays and the result is zero. Such instances may be hiding
    some bugs. So, this work (flexible-array member conversions) will also
    help to get completely rid of those sorts of issues.

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: David Howells
    Reviewed-by: Jarkko Sakkinen

    Gustavo A. R. Silva
     

29 Mar, 2020

1 commit

  • A lockdep circular locking dependency report was seen when running a
    keyutils test:

    [12537.027242] ======================================================
    [12537.059309] WARNING: possible circular locking dependency detected
    [12537.088148] 4.18.0-147.7.1.el8_1.x86_64+debug #1 Tainted: G OE --------- - -
    [12537.125253] ------------------------------------------------------
    [12537.153189] keyctl/25598 is trying to acquire lock:
    [12537.175087] 000000007c39f96c (&mm->mmap_sem){++++}, at: __might_fault+0xc4/0x1b0
    [12537.208365]
    [12537.208365] but task is already holding lock:
    [12537.234507] 000000003de5b58d (&type->lock_class){++++}, at: keyctl_read_key+0x15a/0x220
    [12537.270476]
    [12537.270476] which lock already depends on the new lock.
    [12537.270476]
    [12537.307209]
    [12537.307209] the existing dependency chain (in reverse order) is:
    [12537.340754]
    [12537.340754] -> #3 (&type->lock_class){++++}:
    [12537.367434] down_write+0x4d/0x110
    [12537.385202] __key_link_begin+0x87/0x280
    [12537.405232] request_key_and_link+0x483/0xf70
    [12537.427221] request_key+0x3c/0x80
    [12537.444839] dns_query+0x1db/0x5a5 [dns_resolver]
    [12537.468445] dns_resolve_server_name_to_ip+0x1e1/0x4d0 [cifs]
    [12537.496731] cifs_reconnect+0xe04/0x2500 [cifs]
    [12537.519418] cifs_readv_from_socket+0x461/0x690 [cifs]
    [12537.546263] cifs_read_from_socket+0xa0/0xe0 [cifs]
    [12537.573551] cifs_demultiplex_thread+0x311/0x2db0 [cifs]
    [12537.601045] kthread+0x30c/0x3d0
    [12537.617906] ret_from_fork+0x3a/0x50
    [12537.636225]
    [12537.636225] -> #2 (root_key_user.cons_lock){+.+.}:
    [12537.664525] __mutex_lock+0x105/0x11f0
    [12537.683734] request_key_and_link+0x35a/0xf70
    [12537.705640] request_key+0x3c/0x80
    [12537.723304] dns_query+0x1db/0x5a5 [dns_resolver]
    [12537.746773] dns_resolve_server_name_to_ip+0x1e1/0x4d0 [cifs]
    [12537.775607] cifs_reconnect+0xe04/0x2500 [cifs]
    [12537.798322] cifs_readv_from_socket+0x461/0x690 [cifs]
    [12537.823369] cifs_read_from_socket+0xa0/0xe0 [cifs]
    [12537.847262] cifs_demultiplex_thread+0x311/0x2db0 [cifs]
    [12537.873477] kthread+0x30c/0x3d0
    [12537.890281] ret_from_fork+0x3a/0x50
    [12537.908649]
    [12537.908649] -> #1 (&tcp_ses->srv_mutex){+.+.}:
    [12537.935225] __mutex_lock+0x105/0x11f0
    [12537.954450] cifs_call_async+0x102/0x7f0 [cifs]
    [12537.977250] smb2_async_readv+0x6c3/0xc90 [cifs]
    [12538.000659] cifs_readpages+0x120a/0x1e50 [cifs]
    [12538.023920] read_pages+0xf5/0x560
    [12538.041583] __do_page_cache_readahead+0x41d/0x4b0
    [12538.067047] ondemand_readahead+0x44c/0xc10
    [12538.092069] filemap_fault+0xec1/0x1830
    [12538.111637] __do_fault+0x82/0x260
    [12538.129216] do_fault+0x419/0xfb0
    [12538.146390] __handle_mm_fault+0x862/0xdf0
    [12538.167408] handle_mm_fault+0x154/0x550
    [12538.187401] __do_page_fault+0x42f/0xa60
    [12538.207395] do_page_fault+0x38/0x5e0
    [12538.225777] page_fault+0x1e/0x30
    [12538.243010]
    [12538.243010] -> #0 (&mm->mmap_sem){++++}:
    [12538.267875] lock_acquire+0x14c/0x420
    [12538.286848] __might_fault+0x119/0x1b0
    [12538.306006] keyring_read_iterator+0x7e/0x170
    [12538.327936] assoc_array_subtree_iterate+0x97/0x280
    [12538.352154] keyring_read+0xe9/0x110
    [12538.370558] keyctl_read_key+0x1b9/0x220
    [12538.391470] do_syscall_64+0xa5/0x4b0
    [12538.410511] entry_SYSCALL_64_after_hwframe+0x6a/0xdf
    [12538.435535]
    [12538.435535] other info that might help us debug this:
    [12538.435535]
    [12538.472829] Chain exists of:
    [12538.472829] &mm->mmap_sem --> root_key_user.cons_lock --> &type->lock_class
    [12538.472829]
    [12538.524820] Possible unsafe locking scenario:
    [12538.524820]
    [12538.551431] CPU0 CPU1
    [12538.572654] ---- ----
    [12538.595865] lock(&type->lock_class);
    [12538.613737] lock(root_key_user.cons_lock);
    [12538.644234] lock(&type->lock_class);
    [12538.672410] lock(&mm->mmap_sem);
    [12538.687758]
    [12538.687758] *** DEADLOCK ***
    [12538.687758]
    [12538.714455] 1 lock held by keyctl/25598:
    [12538.732097] #0: 000000003de5b58d (&type->lock_class){++++}, at: keyctl_read_key+0x15a/0x220
    [12538.770573]
    [12538.770573] stack backtrace:
    [12538.790136] CPU: 2 PID: 25598 Comm: keyctl Kdump: loaded Tainted: G
    [12538.844855] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015
    [12538.881963] Call Trace:
    [12538.892897] dump_stack+0x9a/0xf0
    [12538.907908] print_circular_bug.isra.25.cold.50+0x1bc/0x279
    [12538.932891] ? save_trace+0xd6/0x250
    [12538.948979] check_prev_add.constprop.32+0xc36/0x14f0
    [12538.971643] ? keyring_compare_object+0x104/0x190
    [12538.992738] ? check_usage+0x550/0x550
    [12539.009845] ? sched_clock+0x5/0x10
    [12539.025484] ? sched_clock_cpu+0x18/0x1e0
    [12539.043555] __lock_acquire+0x1f12/0x38d0
    [12539.061551] ? trace_hardirqs_on+0x10/0x10
    [12539.080554] lock_acquire+0x14c/0x420
    [12539.100330] ? __might_fault+0xc4/0x1b0
    [12539.119079] __might_fault+0x119/0x1b0
    [12539.135869] ? __might_fault+0xc4/0x1b0
    [12539.153234] keyring_read_iterator+0x7e/0x170
    [12539.172787] ? keyring_read+0x110/0x110
    [12539.190059] assoc_array_subtree_iterate+0x97/0x280
    [12539.211526] keyring_read+0xe9/0x110
    [12539.227561] ? keyring_gc_check_iterator+0xc0/0xc0
    [12539.249076] keyctl_read_key+0x1b9/0x220
    [12539.266660] do_syscall_64+0xa5/0x4b0
    [12539.283091] entry_SYSCALL_64_after_hwframe+0x6a/0xdf

    One way to prevent this deadlock scenario from happening is to not
    allow writing to userspace while holding the key semaphore. Instead,
    an internal buffer is allocated for getting the keys out from the
    read method first before copying them out to userspace without holding
    the lock.

    That requires taking out the __user modifier from all the relevant
    read methods as well as additional changes to not use any userspace
    write helpers. That is,

    1) The put_user() call is replaced by a direct copy.
    2) The copy_to_user() call is replaced by memcpy().
    3) All the fault handling code is removed.

    Compiling on a x86-64 system, the size of the rxrpc_read() function is
    reduced from 3795 bytes to 2384 bytes with this patch.

    Fixes: ^1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Waiman Long
    Signed-off-by: David Howells

    Waiman Long
     

01 Dec, 2019

1 commit

  • Pull powerpc updates from Michael Ellerman:
    "Highlights:

    - Infrastructure for secure boot on some bare metal Power9 machines.
    The firmware support is still in development, so the code here
    won't actually activate secure boot on any existing systems.

    - A change to xmon (our crash handler / pseudo-debugger) to restrict
    it to read-only mode when the kernel is lockdown'ed, otherwise it's
    trivial to drop into xmon and modify kernel data, such as the
    lockdown state.

    - Support for KASLR on 32-bit BookE machines (Freescale / NXP).

    - Fixes for our flush_icache_range() and __kernel_sync_dicache()
    (VDSO) to work with memory ranges >4GB.

    - Some reworks of the pseries CMM (Cooperative Memory Management)
    driver to make it behave more like other balloon drivers and enable
    some cleanups of generic mm code.

    - A series of fixes to our hardware breakpoint support to properly
    handle unaligned watchpoint addresses.

    Plus a bunch of other smaller improvements, fixes and cleanups.

    Thanks to: Alastair D'Silva, Andrew Donnellan, Aneesh Kumar K.V,
    Anthony Steinhauser, Cédric Le Goater, Chris Packham, Chris Smart,
    Christophe Leroy, Christopher M. Riedl, Christoph Hellwig, Claudio
    Carvalho, Daniel Axtens, David Hildenbrand, Deb McLemore, Diana
    Craciun, Eric Richter, Geert Uytterhoeven, Greg Kroah-Hartman, Greg
    Kurz, Gustavo L. F. Walbon, Hari Bathini, Harish, Jason Yan, Krzysztof
    Kozlowski, Leonardo Bras, Mathieu Malaterre, Mauro S. M. Rodrigues,
    Michal Suchanek, Mimi Zohar, Nathan Chancellor, Nathan Lynch, Nayna
    Jain, Nick Desaulniers, Oliver O'Halloran, Qian Cai, Rasmus Villemoes,
    Ravi Bangoria, Sam Bobroff, Santosh Sivaraj, Scott Wood, Thomas Huth,
    Tyrel Datwyler, Vaibhav Jain, Valentin Longchamp, YueHaibing"

    * tag 'powerpc-5.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (144 commits)
    powerpc/fixmap: fix crash with HIGHMEM
    x86/efi: remove unused variables
    powerpc: Define arch_is_kernel_initmem_freed() for lockdep
    powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp
    powerpc: Avoid clang warnings around setjmp and longjmp
    powerpc: Don't add -mabi= flags when building with Clang
    powerpc: Fix Kconfig indentation
    powerpc/fixmap: don't clear fixmap area in paging_init()
    selftests/powerpc: spectre_v2 test must be built 64-bit
    powerpc/powernv: Disable native PCIe port management
    powerpc/kexec: Move kexec files into a dedicated subdir.
    powerpc/32: Split kexec low level code out of misc_32.S
    powerpc/sysdev: drop simple gpio
    powerpc/83xx: map IMMR with a BAT.
    powerpc/32s: automatically allocate BAT in setbat()
    powerpc/ioremap: warn on early use of ioremap()
    powerpc: Add support for GENERIC_EARLY_IOREMAP
    powerpc/fixmap: Use __fix_to_virt() instead of fix_to_virt()
    powerpc/8xx: use the fixmapped IMMR in cpm_reset()
    powerpc/8xx: add __init to cpm1 init functions
    ...

    Linus Torvalds
     

13 Nov, 2019

4 commits

  • Move TPM2 trusted keys code to trusted keys subsystem. The reason
    being it's better to consolidate all the trusted keys code to a single
    location so that it can be maintained sanely.

    Also, utilize existing tpm_send() exported API which wraps the internal
    tpm_transmit_cmd() API.

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

    Sumit Garg
     
  • 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
     

12 Nov, 2019

1 commit

  • The -EKEYREJECTED error returned by existing is_hash_blacklisted() is
    misleading when called for checking against blacklisted hash of a
    binary.

    This patch adds a wrapper function is_binary_blacklisted() to return
    -EPERM error if binary is blacklisted.

    Signed-off-by: Nayna Jain
    Reviewed-by: Mimi Zohar
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1572492694-6520-7-git-send-email-zohar@linux.ibm.com

    Nayna Jain
     

09 Jul, 2019

1 commit

  • Pull request_key improvements from David Howells:
    "These are all request_key()-related, including a fix and some improvements:

    - Fix the lack of a Link permission check on a key found by
    request_key(), thereby enabling request_key() to link keys that
    don't grant this permission to the target keyring (which must still
    grant Write permission).

    Note that the key must be in the caller's keyrings already to be
    found.

    - Invalidate used request_key authentication keys rather than
    revoking them, so that they get cleaned up immediately rather than
    hanging around till the expiry time is passed.

    - Move the RCU locks outwards from the keyring search functions so
    that a request_key_rcu() can be provided. This can be called in RCU
    mode, so it can't sleep and can't upcall - but it can be called
    from LOOKUP_RCU pathwalk mode.

    - Cache the latest positive result of request_key*() temporarily in
    task_struct so that filesystems that make a lot of request_key()
    calls during pathwalk can take advantage of it to avoid having to
    redo the searching. This requires CONFIG_KEYS_REQUEST_CACHE=y.

    It is assumed that the key just found is likely to be used multiple
    times in each step in an RCU pathwalk, and is likely to be reused
    for the next step too.

    Note that the cleanup of the cache is done on TIF_NOTIFY_RESUME,
    just before userspace resumes, and on exit"

    * tag 'keys-request-20190626' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Kill off request_key_async{,_with_auxdata}
    keys: Cache result of request_key*() temporarily in task_struct
    keys: Provide request_key_rcu()
    keys: Move the RCU locks outwards from the keyring search functions
    keys: Invalidate used request_key authentication keys
    keys: Fix request_key() lack of Link perm check on found key

    Linus Torvalds
     

19 Jun, 2019

1 commit


05 Jun, 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 license as published by
    the free software foundation version 2 of the license

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

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

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

    Thomas Gleixner
     

31 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 license as published by
    the free software foundation either version 2 of the license 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 3029 file(s).

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

    Thomas Gleixner
     

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
     

09 Apr, 2019

1 commit

  • Fixes the warning reported by Clang:
    security/keys/trusted.c:146:17: warning: passing an object that
    undergoes default
    argument promotion to 'va_start' has undefined behavior [-Wvarargs]
    va_start(argp, h3);
    ^
    security/keys/trusted.c:126:37: note: parameter of type 'unsigned
    char' is declared here
    unsigned char *h2, unsigned char h3, ...)
    ^
    Specifically, it seems that both the C90 (4.8.1.1) and C11 (7.16.1.4)
    standards explicitly call this out as undefined behavior:

    The parameter parmN is the identifier of the rightmost parameter in
    the variable parameter list in the function definition (the one just
    before the ...). If the parameter parmN is declared with ... or with a
    type that is not compatible with the type that results after
    application of the default argument promotions, the behavior is
    undefined.

    Link: https://github.com/ClangBuiltLinux/linux/issues/41
    Link: https://www.eskimo.com/~scs/cclass/int/sx11c.html
    Suggested-by: David Laight
    Suggested-by: Denis Kenzior
    Suggested-by: James Bottomley
    Suggested-by: Nathan Chancellor
    Signed-off-by: Nick Desaulniers
    Reviewed-by: Nathan Chancellor
    Tested-by: Nathan Chancellor
    Reviewed-by: Jarkko Sakkinen
    Signed-off-by: Jarkko Sakkinen
    Signed-off-by: James Morris

    ndesaulniers@google.com
     

11 Mar, 2019

1 commit

  • …morris/linux-security

    Pull integrity updates from James Morris:
    "Mimi Zohar says:

    'Linux 5.0 introduced the platform keyring to allow verifying the IMA
    kexec kernel image signature using the pre-boot keys. This pull
    request similarly makes keys on the platform keyring accessible for
    verifying the PE kernel image signature.

    Also included in this pull request is a new IMA hook that tags tmp
    files, in policy, indicating the file hash needs to be calculated.
    The remaining patches are cleanup'"

    * 'next-integrity' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
    evm: Use defined constant for UUID representation
    ima: define ima_post_create_tmpfile() hook and add missing call
    evm: remove set but not used variable 'xattr'
    encrypted-keys: fix Opt_err/Opt_error = -1
    kexec, KEYS: Make use of platform keyring for signature verify
    integrity, KEYS: add a reference to platform keyring

    Linus Torvalds
     

23 Feb, 2019

1 commit

  • Align the payload of "user" and "logon" keys so that users of the
    keyrings service can access it as a struct that requires more than
    2-byte alignment. fscrypt currently does this which results in the read
    of fscrypt_key::size being misaligned as it needs 4-byte alignment.

    Align to __alignof__(u64) rather than __alignof__(long) since in the
    future it's conceivable that people would use structs beginning with
    u64, which on some platforms would require more than 'long' alignment.

    Reported-by: Aaro Koskinen
    Fixes: 2aa349f6e37c ("[PATCH] Keys: Export user-defined keyring operations")
    Fixes: 88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers
    Tested-by: Aaro Koskinen
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    Eric Biggers
     

16 Feb, 2019

1 commit

  • In the request_key() upcall mechanism there's a dependency loop by which if
    a key type driver overrides the ->request_key hook and the userspace side
    manages to lose the authorisation key, the auth key and the internal
    construction record (struct key_construction) can keep each other pinned.

    Fix this by the following changes:

    (1) Killing off the construction record and using the auth key instead.

    (2) Including the operation name in the auth key payload and making the
    payload available outside of security/keys/.

    (3) The ->request_key hook is given the authkey instead of the cons
    record and operation name.

    Changes (2) and (3) allow the auth key to naturally be cleaned up if the
    keyring it is in is destroyed or cleared or the auth key is unlinked.

    Fixes: 7ee02a316600 ("keys: Fix dependency loop between construction record and auth key")
    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

05 Feb, 2019

1 commit

  • commit 9dc92c45177a ("integrity: Define a trusted platform keyring")
    introduced a .platform keyring for storing preboot keys, used for
    verifying kernel image signatures. Currently only IMA-appraisal is able
    to use the keyring to verify kernel images that have their signature
    stored in xattr.

    This patch exposes the .platform keyring, making it accessible for
    verifying PE signed kernel images as well.

    Suggested-by: Mimi Zohar
    Signed-off-by: Kairui Song
    Cc: David Howells
    [zohar@linux.ibm.com: fixed checkpatch errors, squashed with patch fix]
    Signed-off-by: Mimi Zohar

    Kairui Song
     

26 Oct, 2018

2 commits

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

    Denis Kenzior
     
  • Provide the missing asymmetric key subops for new key type ops. This
    include query, encrypt, decrypt and create signature. Verify signature
    already exists. Also provided are accessor functions for this:

    int query_asymmetric_key(const struct key *key,
    struct kernel_pkey_query *info);

    int encrypt_blob(struct kernel_pkey_params *params,
    const void *data, void *enc);
    int decrypt_blob(struct kernel_pkey_params *params,
    const void *enc, void *data);
    int create_signature(struct kernel_pkey_params *params,
    const void *data, void *enc);

    The public_key_signature struct gains an encoding field to carry the
    encoding for verify_signature().

    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
     

16 Jun, 2018

1 commit

  • As we move stuff around, some doc references are broken. Fix some of
    them via this script:
    ./scripts/documentation-file-ref-check --fix

    Manually checked if the produced result is valid, removing a few
    false-positives.

    Acked-by: Takashi Iwai
    Acked-by: Masami Hiramatsu
    Acked-by: Stephen Boyd
    Acked-by: Charles Keepax
    Acked-by: Mathieu Poirier
    Reviewed-by: Coly Li
    Signed-off-by: Mauro Carvalho Chehab
    Acked-by: Jonathan Corbet

    Mauro Carvalho Chehab
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

29 Aug, 2017

1 commit

  • Since the 'expiry' variable of 'struct key_preparsed_payload' has been
    changed to 'time64_t' type, which is year 2038 safe on 32bits system.

    In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type
    when copying ticket expires time to 'prep->expiry', then this patch
    introduces two helper functions to help convert 'u32' to 'time64_t'
    type.

    This patch also uses ktime_get_real_seconds() to get current time instead
    of get_seconds() which is not year 2038 safe on 32bits system.

    Signed-off-by: Baolin Wang
    Signed-off-by: David Howells

    Baolin Wang
     

04 Apr, 2017

1 commit

  • The first argument to the restrict_link_func_t functions was a keyring
    pointer. These functions are called by the key subsystem with this
    argument set to the destination keyring, but restrict_link_by_signature
    expects a pointer to the relevant trusted keyring.

    Restrict functions may need something other than a single struct key
    pointer to allow or reject key linkage, so the data used to make that
    decision (such as the trust keyring) is moved to a new, fourth
    argument. The first argument is now always the destination keyring.

    Signed-off-by: Mat Martineau

    Mat Martineau
     

03 Apr, 2017

1 commit

  • Add the following:

    (1) A new system keyring that is used to store information about
    blacklisted certificates and signatures.

    (2) A new key type (called 'blacklist') that is used to store a
    blacklisted hash in its description as a hex string. The key accepts
    no payload.

    (3) The ability to configure a list of blacklisted hashes into the kernel
    at build time. This is done by setting
    CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes
    that are in the form:

    "", "", ..., ""

    where each is a hex string representation of the hash and must
    include all necessary leading zeros to pad the hash to the right size.

    The above are enabled with CONFIG_SYSTEM_BLACKLIST_KEYRING.

    Once the kernel is booted, the blacklist keyring can be listed:

    root@andromeda ~]# keyctl show %:.blacklist
    Keyring
    723359729 ---lswrv 0 0 keyring: .blacklist
    676257228 ---lswrv 0 0 \_ blacklist: 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46

    The blacklist cannot currently be modified by userspace, but it will be
    possible to load it, for example, from the UEFI blacklist database.

    A later commit will make it possible to load blacklisted asymmetric keys in
    here too.

    Signed-off-by: David Howells

    David Howells
     

02 Mar, 2017

1 commit

  • rcu_dereference_key() and user_key_payload() are currently being used in
    two different, incompatible ways:

    (1) As a wrapper to rcu_dereference() - when only the RCU read lock used
    to protect the key.

    (2) As a wrapper to rcu_dereference_protected() - when the key semaphor is
    used to protect the key and the may be being modified.

    Fix this by splitting both of the key wrappers to produce:

    (1) RCU accessors for keys when caller has the key semaphore locked:

    dereference_key_locked()
    user_key_payload_locked()

    (2) RCU accessors for keys when caller holds the RCU read lock:

    dereference_key_rcu()
    user_key_payload_rcu()

    This should fix following warning in the NFS idmapper

    ===============================
    [ INFO: suspicious RCU usage. ]
    4.10.0 #1 Tainted: G W
    -------------------------------
    ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
    other info that might help us debug this:
    rcu_scheduler_active = 2, debug_locks = 0
    1 lock held by mount.nfs/5987:
    #0: (rcu_read_lock){......}, at: [] nfs_idmap_get_key+0x15c/0x420 [nfsv4]
    stack backtrace:
    CPU: 1 PID: 5987 Comm: mount.nfs Tainted: G W 4.10.0 #1
    Call Trace:
    dump_stack+0xe8/0x154 (unreliable)
    lockdep_rcu_suspicious+0x140/0x190
    nfs_idmap_get_key+0x380/0x420 [nfsv4]
    nfs_map_name_to_uid+0x2a0/0x3b0 [nfsv4]
    decode_getfattr_attrs+0xfac/0x16b0 [nfsv4]
    decode_getfattr_generic.constprop.106+0xbc/0x150 [nfsv4]
    nfs4_xdr_dec_lookup_root+0xac/0xb0 [nfsv4]
    rpcauth_unwrap_resp+0xe8/0x140 [sunrpc]
    call_decode+0x29c/0x910 [sunrpc]
    __rpc_execute+0x140/0x8f0 [sunrpc]
    rpc_run_task+0x170/0x200 [sunrpc]
    nfs4_call_sync_sequence+0x68/0xa0 [nfsv4]
    _nfs4_lookup_root.isra.44+0xd0/0xf0 [nfsv4]
    nfs4_lookup_root+0xe0/0x350 [nfsv4]
    nfs4_lookup_root_sec+0x70/0xa0 [nfsv4]
    nfs4_find_root_sec+0xc4/0x100 [nfsv4]
    nfs4_proc_get_rootfh+0x5c/0xf0 [nfsv4]
    nfs4_get_rootfh+0x6c/0x190 [nfsv4]
    nfs4_server_common_setup+0xc4/0x260 [nfsv4]
    nfs4_create_server+0x278/0x3c0 [nfsv4]
    nfs4_remote_mount+0x50/0xb0 [nfsv4]
    mount_fs+0x74/0x210
    vfs_kern_mount+0x78/0x220
    nfs_do_root_mount+0xb0/0x140 [nfsv4]
    nfs4_try_mount+0x60/0x100 [nfsv4]
    nfs_fs_mount+0x5ec/0xda0 [nfs]
    mount_fs+0x74/0x210
    vfs_kern_mount+0x78/0x220
    do_mount+0x254/0xf70
    SyS_mount+0x94/0x100
    system_call+0x38/0xe0

    Reported-by: Jan Stancek
    Signed-off-by: David Howells
    Tested-by: Jan Stancek
    Signed-off-by: James Morris

    David Howells
     

14 Jun, 2016

1 commit


12 Apr, 2016

6 commits

  • Add a config option (IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY)
    that, when enabled, allows keys to be added to the IMA keyrings by
    userspace - with the restriction that each must be signed by a key in the
    system trusted keyrings.

    EPERM will be returned if this option is disabled, ENOKEY will be returned if
    no authoritative key can be found and EKEYREJECTED will be returned if the
    signature doesn't match. Other errors such as ENOPKG may also be returned.

    If this new option is enabled, the builtin system keyring is searched, as is
    the secondary system keyring if that is also enabled. Intermediate keys
    between the builtin system keyring and the key being added can be added to
    the secondary keyring (which replaces .ima_mok) to form a trust chain -
    provided they are also validly signed by a key in one of the trusted keyrings.

    The .ima_mok keyring is then removed and the IMA blacklist keyring gets its
    own config option (IMA_BLACKLIST_KEYRING).

    Signed-off-by: David Howells
    Signed-off-by: Mimi Zohar

    David Howells
     
  • Add a secondary system keyring that can be added to by root whilst the
    system is running - provided the key being added is vouched for by a key
    built into the kernel or already added to the secondary keyring.

    Rename .system_keyring to .builtin_trusted_keys to distinguish it more
    obviously from the new keyring (called .secondary_trusted_keys).

    The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.

    If the secondary keyring is enabled, a link is created from that to
    .builtin_trusted_keys so that the the latter will automatically be searched
    too if the secondary keyring is searched.

    Signed-off-by: David Howells

    David Howells
     
  • Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
    meaningful. Also we can drop the trusted flag from the preparse structure.

    Given this, we no longer need to pass the key flags through to
    restrict_link().

    Further, we can now get rid of keyring_restrict_trusted_only() also.

    Signed-off-by: David Howells

    David Howells
     
  • 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

    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

    David Howells
     
  • Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
    generalised.

    Signed-off-by: David Howells

    David Howells
     

06 Apr, 2016

1 commit

  • 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