29 Apr, 2020

1 commit


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
     

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
     

09 Jul, 2019

2 commits

  • Pull keyring ACL support from David Howells:
    "This changes the permissions model used by keys and keyrings to be
    based on an internal ACL by the following means:

    - Replace the permissions mask internally with an ACL that contains a
    list of ACEs, each with a specific subject with a permissions mask.
    Potted default ACLs are available for new keys and keyrings.

    ACE subjects can be macroised to indicate the UID and GID specified
    on the key (which remain). Future commits will be able to add
    additional subject types, such as specific UIDs or domain
    tags/namespaces.

    Also split a number of permissions to give finer control. Examples
    include splitting the revocation permit from the change-attributes
    permit, thereby allowing someone to be granted permission to revoke
    a key without allowing them to change the owner; also the ability
    to join a keyring is split from the ability to link to it, thereby
    stopping a process accessing a keyring by joining it and thus
    acquiring use of possessor permits.

    - Provide a keyctl to allow the granting or denial of one or more
    permits to a specific subject. Direct access to the ACL is not
    granted, and the ACL cannot be viewed"

    * tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
    keys: Provide KEYCTL_GRANT_PERMISSION
    keys: Replace uid/gid/perm permissions checking with an ACL

    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
     

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

1 commit

  • Create key domain tags for network namespaces and make it possible to
    automatically tag keys that are used by networked services (e.g. AF_RXRPC,
    AFS, DNS) with the default network namespace if not set by the caller.

    This allows keys with the same description but in different namespaces to
    coexist within a 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
     

21 May, 2019

1 commit


16 May, 2019

1 commit

  • Allow used DNS resolver keys to be invalidated after use if the caller is
    doing its own caching of the results. This reduces the amount of resources
    required.

    Fix AFS to invalidate DNS results to kill off permanent failure records
    that get lodged in the resolver keyring and prevent future lookups from
    happening.

    Fixes: 0a5143f2f89c ("afs: Implement VL server rotation")
    Signed-off-by: David Howells

    David Howells
     

12 Apr, 2019

1 commit


05 Oct, 2018

1 commit

  • Allow the DNS resolver to retrieve a set of servers and their associated
    addresses, ports, preference and weight ratings.

    In terms of communication with userspace, "srv=1" is added to the callout
    string (the '1' indicating the maximum data version supported by the
    kernel) to ask the userspace side for this.

    If the userspace side doesn't recognise it, it will ignore the option and
    return the usual text address list.

    If the userspace side does recognise it, it will return some binary data
    that begins with a zero byte that would cause the string parsers to give an
    error. The second byte contains the version of the data in the blob (this
    may be between 1 and the version specified in the callout data). The
    remainder of the payload is version-specific.

    In version 1, the payload looks like (note that this is packed):

    u8 Non-string marker (ie. 0)
    u8 Content (0 => Server list)
    u8 Version (ie. 1)
    u8 Source (eg. DNS_RECORD_FROM_DNS_SRV)
    u8 Status (eg. DNS_LOOKUP_GOOD)
    u8 Number of servers
    foreach-server {
    u16 Name length (LE)
    u16 Priority (as per SRV record) (LE)
    u16 Weight (as per SRV record) (LE)
    u16 Port (LE)
    u8 Source (eg. DNS_RECORD_FROM_NSS)
    u8 Status (eg. DNS_LOOKUP_GOT_NOT_FOUND)
    u8 Protocol (eg. DNS_SERVER_PROTOCOL_UDP)
    u8 Number of addresses
    char[] Name (not NUL-terminated)
    foreach-address {
    u8 Family (AF_INET{,6})
    union {
    u8[4] ipv4_addr
    u8[16] ipv6_addr
    }
    }
    }

    This can then be used to fetch a whole cell's VL-server configuration for
    AFS, for example.

    Signed-off-by: David Howells
    Signed-off-by: David S. Miller

    David Howells
     

25 Jul, 2018

1 commit


17 Jul, 2018

1 commit

  • My recent fix for dns_resolver_preparse() printing very long strings was
    incomplete, as shown by syzbot which still managed to hit the
    WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:

    precision 50001 too large
    WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0

    The bug this time isn't just a printing bug, but also a logical error
    when multiple options ("#"-separated strings) are given in the key
    payload. Specifically, when separating an option string into name and
    value, if there is no value then the name is incorrectly considered to
    end at the end of the key payload, rather than the end of the current
    option. This bypasses validation of the option length, and also means
    that specifying multiple options is broken -- which presumably has gone
    unnoticed as there is currently only one valid option anyway.

    A similar problem also applied to option values, as the kstrtoul() when
    parsing the "dnserror" option will read past the end of the current
    option and into the next option.

    Fix these bugs by correctly computing the length of the option name and
    by copying the option value, null-terminated, into a temporary buffer.

    Reproducer for the WARN_ONCE() that syzbot hit:

    perl -e 'print "#A#", "\0" x 50000' | keyctl padd dns_resolver desc @s

    Reproducer for "dnserror" option being parsed incorrectly (expected
    behavior is to fail when seeing the unknown option "foo", actual
    behavior was to read the dnserror value as "1#foo" and fail there):

    perl -e 'print "#dnserror=1#foo\0"' | keyctl padd dns_resolver desc @s

    Reported-by: syzbot
    Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
    Signed-off-by: Eric Biggers
    Signed-off-by: David S. Miller

    Eric Biggers
     

18 Apr, 2018

1 commit

  • Adding a dns_resolver key whose payload contains a very long option name
    resulted in that string being printed in full. This hit the WARN_ONCE()
    in set_precision() during the printk(), because printk() only supports a
    precision of up to 32767 bytes:

    precision 1000000 too large
    WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0

    Fix it by limiting option strings (combined name + value) to a much more
    reasonable 128 bytes. The exact limit is arbitrary, but currently the
    only recognized option is formatted as "dnserror=%lu" which fits well
    within this limit.

    Also ratelimit the printks.

    Reproducer:

    perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s

    This bug was found using syzkaller.

    Reported-by: Mark Rutland
    Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
    Signed-off-by: Eric Biggers
    Signed-off-by: David S. Miller

    Eric Biggers
     

27 Mar, 2018

1 commit

  • Prefer the direct use of octal for permissions.

    Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
    and some typing.

    Miscellanea:

    o Whitespace neatening around these conversions.

    Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches
     

06 Feb, 2018

1 commit

  • Support the AFS dynamic root which is a pseudo-volume that doesn't connect
    to any server resource, but rather is just a root directory that
    dynamically creates mountpoint directories where the name of such a
    directory is the name of the cell.

    Such a mount can be created thus:

    mount -t afs none /afs -o dyn

    Dynamic root superblocks aren't shared except by bind mounts and
    propagation. Cell root volumes can then be mounted by referring to them by
    name, e.g.:

    ls /afs/grand.central.org/
    ls /afs/.grand.central.org/

    The kernel will upcall to consult the DNS if the address wasn't supplied
    directly.

    Signed-off-by: David Howells

    David Howells
     

18 Oct, 2017

1 commit

  • Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
    error into one field such that:

    (1) The instantiation state can be modified/read atomically.

    (2) The error can be accessed atomically with the state.

    (3) The error isn't stored unioned with the payload pointers.

    This deals with the problem that the state is spread over three different
    objects (two bits and a separate variable) and reading or updating them
    atomically isn't practical, given that not only can uninstantiated keys
    change into instantiated or rejected keys, but rejected keys can also turn
    into instantiated keys - and someone accessing the key might not be using
    any locking.

    The main side effect of this problem is that what was held in the payload
    may change, depending on the state. For instance, you might observe the
    key to be in the rejected state. You then read the cached error, but if
    the key semaphore wasn't locked, the key might've become instantiated
    between the two reads - and you might now have something in hand that isn't
    actually an error code.

    The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
    code if the key is negatively instantiated. The key_is_instantiated()
    function is replaced with key_is_positive() to avoid confusion as negative
    keys are also 'instantiated'.

    Additionally, barriering is included:

    (1) Order payload-set before state-set during instantiation.

    (2) Order state-read before payload-read when using the key.

    Further separate barriering is necessary if RCU is being used to access the
    payload content after reading the payload pointers.

    Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
    Cc: stable@vger.kernel.org # v4.4+
    Reported-by: Eric Biggers
    Signed-off-by: David Howells
    Reviewed-by: Eric Biggers

    David Howells
     

04 Mar, 2017

1 commit

  • Pull sched.h split-up from Ingo Molnar:
    "The point of these changes is to significantly reduce the
    header footprint, to speed up the kernel build and to
    have a cleaner header structure.

    After these changes the new 's typical preprocessed
    size goes down from a previous ~0.68 MB (~22K lines) to ~0.45 MB (~15K
    lines), which is around 40% faster to build on typical configs.

    Not much changed from the last version (-v2) posted three weeks ago: I
    eliminated quirks, backmerged fixes plus I rebased it to an upstream
    SHA1 from yesterday that includes most changes queued up in -next plus
    all sched.h changes that were pending from Andrew.

    I've re-tested the series both on x86 and on cross-arch defconfigs,
    and did a bisectability test at a number of random points.

    I tried to test as many build configurations as possible, but some
    build breakage is probably still left - but it should be mostly
    limited to architectures that have no cross-compiler binaries
    available on kernel.org, and non-default configurations"

    * 'WIP.sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (146 commits)
    sched/headers: Clean up
    sched/headers: Remove #ifdefs from
    sched/headers: Remove the include from
    sched/headers, hrtimer: Remove the include from
    sched/headers, x86/apic: Remove the header inclusion from
    sched/headers, timers: Remove the include from
    sched/headers: Remove from
    sched/headers: Remove from
    sched/core: Remove unused prefetch_stack()
    sched/headers: Remove from
    sched/headers: Remove the 'init_pid_ns' prototype from
    sched/headers: Remove from
    sched/headers: Remove from
    sched/headers: Remove the runqueue_is_locked() prototype
    sched/headers: Remove from
    sched/headers: Remove from
    sched/headers: Remove from
    sched/headers: Remove from
    sched/headers: Remove the include from
    sched/headers: Remove from
    ...

    Linus Torvalds
     

02 Mar, 2017

2 commits

  • Add #include dependencies to all .c files rely on sched.h
    doing that for them.

    Note that even if the count where we need to add extra headers seems high,
    it's still a net win, because is included in over
    2,200 files ...

    Acked-by: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • 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
     

12 Apr, 2016

1 commit

  • Add a facility whereby proposed new links to be added to a keyring can be
    vetted, permitting them to be rejected if necessary. This can be used to
    block public keys from which the signature cannot be verified or for which
    the signature verification fails. It could also be used to provide
    blacklisting.

    This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.

    To this end:

    (1) A function pointer is added to the key struct that, if set, points to
    the vetting function. This is called as:

    int (*restrict_link)(struct key *keyring,
    const struct key_type *key_type,
    unsigned long key_flags,
    const union key_payload *key_payload),

    where 'keyring' will be the keyring being added to, key_type and
    key_payload will describe the key being added and key_flags[*] can be
    AND'ed with KEY_FLAG_TRUSTED.

    [*] This parameter will be removed in a later patch when
    KEY_FLAG_TRUSTED is removed.

    The function should return 0 to allow the link to take place or an
    error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
    link.

    The pointer should not be set directly, but rather should be set
    through keyring_alloc().

    Note that if called during add_key(), preparse is called before this
    method, but a key isn't actually allocated until after this function
    is called.

    (2) KEY_ALLOC_BYPASS_RESTRICTION is added. This can be passed to
    key_create_or_update() or key_instantiate_and_link() to bypass the
    restriction check.

    (3) KEY_FLAG_TRUSTED_ONLY is removed. The entire contents of a keyring
    with this restriction emplaced can be considered 'trustworthy' by
    virtue of being in the keyring when that keyring is consulted.

    (4) key_alloc() and keyring_alloc() take an extra argument that will be
    used to set restrict_link in the new key. This ensures that the
    pointer is set before the key is published, thus preventing a window
    of unrestrictedness. Normally this argument will be NULL.

    (5) As a temporary affair, keyring_restrict_trusted_only() is added. It
    should be passed to keyring_alloc() as the extra argument instead of
    setting KEY_FLAG_TRUSTED_ONLY on a keyring. This will be replaced in
    a later patch with functions that look in the appropriate places for
    authoritative keys.

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

    David Howells
     

19 Nov, 2015

1 commit

  • Changes the definition of the pointer _expiry from time_t to
    time64_t. This is to handle the Y2038 problem where time_t
    will overflow in the year 2038. The change is safe because
    the kernel subsystems that call dns_query pass NULL.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Aya Mahfouz
    Signed-off-by: David S. Miller

    Aya Mahfouz
     

21 Oct, 2015

1 commit

  • Merge the type-specific data with the payload data into one four-word chunk
    as it seems pointless to keep them separate.

    Use user_key_payload() for accessing the payloads of overloaded
    user-defined keys.

    Signed-off-by: David Howells
    cc: linux-cifs@vger.kernel.org
    cc: ecryptfs@vger.kernel.org
    cc: linux-ext4@vger.kernel.org
    cc: linux-f2fs-devel@lists.sourceforge.net
    cc: linux-nfs@vger.kernel.org
    cc: ceph-devel@vger.kernel.org
    cc: linux-ima-devel@lists.sourceforge.net

    David Howells
     

30 Sep, 2014

1 commit


17 Sep, 2014

3 commits

  • Make the key matching functions pointed to by key_match_data::cmp return bool
    rather than int.

    Signed-off-by: David Howells
    Acked-by: Vivek Goyal

    David Howells
     
  • A previous patch added a ->match_preparse() method to the key type. This is
    allowed to override the function called by the iteration algorithm.
    Therefore, we can just set a default that simply checks for an exact match of
    the key description with the original criterion data and allow match_preparse
    to override it as needed.

    The key_type::match op is then redundant and can be removed, as can the
    user_match() function.

    Signed-off-by: David Howells
    Acked-by: Vivek Goyal

    David Howells
     
  • Preparse the match data. This provides several advantages:

    (1) The preparser can reject invalid criteria up front.

    (2) The preparser can convert the criteria to binary data if necessary (the
    asymmetric key type really wants to do binary comparison of the key IDs).

    (3) The preparser can set the type of search to be performed. This means
    that it's not then a one-off setting in the key type.

    (4) The preparser can set an appropriate comparator function.

    Signed-off-by: David Howells
    Acked-by: Vivek Goyal

    David Howells
     

23 Jul, 2014

2 commits


21 Jul, 2014

1 commit


18 Jul, 2014

1 commit

  • Special kernel keys, such as those used to hold DNS results for AFS, CIFS and
    NFS and those used to hold idmapper results for NFS, used to be
    'invalidateable' with key_revoke(). However, since the default permissions for
    keys were reduced:

    Commit: 96b5c8fea6c0861621051290d705ec2e971963f1
    KEYS: Reduce initial permissions on keys

    it has become impossible to do this.

    Add a key flag (KEY_FLAG_ROOT_CAN_INVAL) that will permit a key to be
    invalidated by root. This should not be used for system keyrings as the
    garbage collector will try and remove any invalidate key. For system keyrings,
    KEY_FLAG_ROOT_CAN_CLEAR can be used instead.

    After this, from userspace, keyctl_invalidate() and "keyctl invalidate" can be
    used by any possessor of CAP_SYS_ADMIN (typically root) to invalidate DNS and
    idmapper keys. Invalidated keys are immediately garbage collected and will be
    immediately rerequested if needed again.

    Signed-off-by: David Howells
    Tested-by: Steve Dickson

    David Howells
     

12 Jun, 2014

1 commit


11 Jun, 2014

1 commit


05 Jun, 2014

1 commit


07 Dec, 2013

1 commit

  • Several files refer to an old address for the Free Software Foundation
    in the file header comment. Resolve by replacing the address with
    the URL so that we do not have to keep
    updating the header comments anytime the address changes.

    CC: John Fastabend
    CC: Alex Duyck
    CC: Marcel Holtmann
    CC: Gustavo Padovan
    CC: Johan Hedberg
    CC: Jamal Hadi Salim
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller

    Jeff Kirsher
     

13 Jul, 2013

1 commit


17 Dec, 2012

1 commit

  • Pull security subsystem updates from James Morris:
    "A quiet cycle for the security subsystem with just a few maintenance
    updates."

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
    Smack: create a sysfs mount point for smackfs
    Smack: use select not depends in Kconfig
    Yama: remove locking from delete path
    Yama: add RCU to drop read locking
    drivers/char/tpm: remove tasklet and cleanup
    KEYS: Use keyring_alloc() to create special keyrings
    KEYS: Reduce initial permissions on keys
    KEYS: Make the session and process keyrings per-thread
    seccomp: Make syscall skipping and nr changes more consistent
    key: Fix resource leak
    keys: Fix unreachable code
    KEYS: Add payload preparsing opportunity prior to key instantiate or update

    Linus Torvalds
     

15 Oct, 2012

1 commit

  • Pull module signing support from Rusty Russell:
    "module signing is the highlight, but it's an all-over David Howells frenzy..."

    Hmm "Magrathea: Glacier signing key". Somebody has been reading too much HHGTTG.

    * 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (37 commits)
    X.509: Fix indefinite length element skip error handling
    X.509: Convert some printk calls to pr_devel
    asymmetric keys: fix printk format warning
    MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checking
    MODSIGN: Make mrproper should remove generated files.
    MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certs
    MODSIGN: Use the same digest for the autogen key sig as for the module sig
    MODSIGN: Sign modules during the build process
    MODSIGN: Provide a script for generating a key ID from an X.509 cert
    MODSIGN: Implement module signature checking
    MODSIGN: Provide module signing public keys to the kernel
    MODSIGN: Automatically generate module signing keys if missing
    MODSIGN: Provide Kconfig options
    MODSIGN: Provide gitignore and make clean rules for extra files
    MODSIGN: Add FIPS policy
    module: signature checking hook
    X.509: Add a crypto key parser for binary (DER) X.509 certificates
    MPILIB: Provide a function to read raw data into an MPI
    X.509: Add an ASN.1 decoder
    X.509: Add simple ASN.1 grammar compiler
    ...

    Linus Torvalds
     

08 Oct, 2012

1 commit

  • Give the key type the opportunity to preparse the payload prior to the
    instantiation and update routines being called. This is done with the
    provision of two new key type operations:

    int (*preparse)(struct key_preparsed_payload *prep);
    void (*free_preparse)(struct key_preparsed_payload *prep);

    If the first operation is present, then it is called before key creation (in
    the add/update case) or before the key semaphore is taken (in the update and
    instantiate cases). The second operation is called to clean up if the first
    was called.

    preparse() is given the opportunity to fill in the following structure:

    struct key_preparsed_payload {
    char *description;
    void *type_data[2];
    void *payload;
    const void *data;
    size_t datalen;
    size_t quotalen;
    };

    Before the preparser is called, the first three fields will have been cleared,
    the payload pointer and size will be stored in data and datalen and the default
    quota size from the key_type struct will be stored into quotalen.

    The preparser may parse the payload in any way it likes and may store data in
    the type_data[] and payload fields for use by the instantiate() and update()
    ops.

    The preparser may also propose a description for the key by attaching it as a
    string to the description field. This can be used by passing a NULL or ""
    description to the add_key() system call or the key_create_or_update()
    function. This cannot work with request_key() as that required the description
    to tell the upcall about the key to be created.

    This, for example permits keys that store PGP public keys to generate their own
    name from the user ID and public key fingerprint in the key.

    The instantiate() and update() operations are then modified to look like this:

    int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
    int (*update)(struct key *key, struct key_preparsed_payload *prep);

    and the new payload data is passed in *prep, whether or not it was preparsed.

    Signed-off-by: David Howells
    Signed-off-by: Rusty Russell

    David Howells