20 Jul, 2007

1 commit

  • Slab destructors were no longer supported after Christoph's
    c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
    BUGs for both slab and slub, and slob never supported them
    either.

    This rips out support for the dtor pointer from kmem_cache_create()
    completely and fixes up every single callsite in the kernel (there were
    about 224, not including the slab allocator definitions themselves,
    or the documentation references).

    Signed-off-by: Paul Mundt

    Paul Mundt
     

07 Feb, 2007

1 commit

  • Fix the key serial number collision avoidance code in key_alloc_serial().

    This didn't use to be so much of a problem as the key serial numbers were
    allocated from a simple incremental counter, and it would have to go through
    two billion keys before it could possibly encounter a collision. However, now
    that random numbers are used instead, collisions are much more likely.

    This is fixed by finding a hole in the rbtree where the next unused serial
    number ought to be and using that by going almost back to the top of the
    insertion routine and redoing the insertion with the new serial number rather
    than trying to be clever and attempting to work out the insertion point
    pointer directly.

    This fixes kernel BZ #7727.

    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

08 Dec, 2006

3 commits

  • Signed-off-by: Eric Sesterhenn
    Signed-off-by: Alexey Dobriyan
    Acked-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Sesterhenn
     
  • Replace all uses of kmem_cache_t with struct kmem_cache.

    The patch was generated using the following script:

    #!/bin/sh
    #
    # Replace one string by another in all the kernel sources.
    #

    set -e

    for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
    quilt add $file
    sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
    mv /tmp/$$ $file
    quilt refresh
    done

    The script was run like this

    sh replace kmem_cache_t "struct kmem_cache"

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     
  • SLAB_KERNEL is an alias of GFP_KERNEL.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

22 Nov, 2006

1 commit

  • Pass the work_struct pointer to the work function rather than context data.
    The work function can use container_of() to work out the data.

    For the cases where the container of the work_struct may go away the moment the
    pending bit is cleared, it is made possible to defer the release of the
    structure by deferring the clearing of the pending bit.

    To make this work, an extra flag is introduced into the management side of the
    work_struct. This governs auto-release of the structure upon execution.

    Ordinarily, the work queue executor would release the work_struct for further
    scheduling or deallocation by clearing the pending bit prior to jumping to the
    work function. This means that, unless the driver makes some guarantee itself
    that the work_struct won't go away, the work function may not access anything
    else in the work_struct or its container lest they be deallocated.. This is a
    problem if the auxiliary data is taken away (as done by the last patch).

    However, if the pending bit is *not* cleared before jumping to the work
    function, then the work function *may* access the work_struct and its container
    with no problems. But then the work function must itself release the
    work_struct by calling work_release().

    In most cases, automatic release is fine, so this is the default. Special
    initiators exist for the non-auto-release case (ending in _NAR).

    Signed-Off-By: David Howells

    David Howells
     

28 Jun, 2006

1 commit

  • Add more poison values to include/linux/poison.h. It's not clear to me
    whether some others should be added or not, so I haven't added any of
    these:

    ./include/linux/libata.h:#define ATA_TAG_POISON 0xfafbfcfdU
    ./arch/ppc/8260_io/fcc_enet.c:1918: memset((char *)(&(immap->im_dprambase[(mem_addr+64)])), 0x88, 32);
    ./drivers/usb/mon/mon_text.c:429: memset(mem, 0xe5, sizeof(struct mon_event_text));
    ./drivers/char/ftape/lowlevel/ftape-ctl.c:738: memset(ft_buffer[i]->address, 0xAA, FT_BUFF_SIZE);
    ./drivers/block/sx8.c:/* 0xf is just arbitrary, non-zero noise; this is sorta like poisoning */

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

27 Jun, 2006

2 commits

  • Cause key_alloc_serial() to generate key serial numbers randomly rather than
    in linear sequence.

    Using an linear sequence permits a covert communication channel to be
    established, in which one process can communicate with another by creating or
    not creating new keys within a certain timeframe. The second process can
    probe for the expected next key serial number and judge its existence by the
    error returned.

    This is a problem as the serial number namespace is globally shared between
    all tasks, regardless of their context.

    For more information on this topic, this old TCSEC guide is recommended:

    http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-030.html

    Signed-off-by: Michael LeMay
    Signed-off-by: James Morris
    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael LeMay
     
  • Add the ability for key creation to overrun the user's quota in some
    circumstances - notably when a session keyring is created and assigned to a
    process that didn't previously have one.

    This means it's still possible to log in, should PAM require the creation of a
    new session keyring, and fix an overburdened key quota.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

23 Jun, 2006

2 commits

  • Add a revocation notification method to the key type and calls it whilst
    the key's semaphore is still write-locked after setting the revocation
    flag.

    The patch then uses this to maintain a reference on the task_struct of the
    process that calls request_key() for as long as the authorisation key
    remains unrevoked.

    This fixes a potential race between two processes both of which have
    assumed the authority to instantiate a key (one may have forked the other
    for example). The problem is that there's no locking around the check for
    revocation of the auth key and the use of the task_struct it points to, nor
    does the auth key keep a reference on the task_struct.

    Access to the "context" pointer in the auth key must thenceforth be done
    with the auth key semaphore held. The revocation method is called with the
    target key semaphore held write-locked and the search of the context
    process's keyrings is done with the auth key semaphore read-locked.

    The check for the revocation state of the auth key just prior to searching
    it is done after the auth key is read-locked for the search. This ensures
    that the auth key can't be revoked between the check and the search.

    The revocation notification method is added so that the context task_struct
    can be released as soon as instantiation happens rather than waiting for
    the auth key to be destroyed, thus avoiding the unnecessary pinning of the
    requesting process.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • Introduce SELinux hooks to support the access key retention subsystem
    within the kernel. Incorporate new flask headers from a modified version
    of the SELinux reference policy, with support for the new security class
    representing retained keys. Extend the "key_alloc" security hook with a
    task parameter representing the intended ownership context for the key
    being allocated. Attach security information to root's default keyrings
    within the SELinux initialization routine.

    Has passed David's testsuite.

    Signed-off-by: Michael LeMay
    Signed-off-by: David Howells
    Signed-off-by: James Morris
    Acked-by: Chris Wright
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael LeMay
     

21 Apr, 2006

1 commit


11 Apr, 2006

1 commit

  • This fixes the problem of an oops occuring when a user attempts to add a
    key to a non-keyring key [CVE-2006-1522].

    The problem is that __keyring_search_one() doesn't check that the
    keyring it's been given is actually a keyring.

    I've fixed this problem by:

    (1) declaring that caller of __keyring_search_one() must guarantee that
    the keyring is a keyring; and

    (2) making key_create_or_update() check that the keyring is a keyring,
    and return -ENOTDIR if it isn't.

    This can be tested by:

    keyctl add user b b `keyctl add user a a @s`

    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

26 Mar, 2006

2 commits

  • Cause an attempt to add a duplicate non-updateable key (such as a keyring) to
    a keyring to discard the extant copy in favour of the new one rather than
    failing with EEXIST:

    # do the test in an empty session
    keyctl session
    # create a new keyring called "a" and attach to session
    keyctl newring a @s
    # create another new keyring called "a" and attach to session,
    # displacing the keyring added by the second command:
    keyctl newring a @s

    Without this patch, the third command will fail.

    For updateable keys (such as those of "user" type), the update method will
    still be called rather than a new key being created.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • Make key quota detection generate an error if either quota is exceeded rather
    than only if both quotas are exceeded.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

07 Jan, 2006

2 commits


07 Nov, 2005

1 commit

  • This is the security/ part of the big kfree cleanup patch.

    Remove pointless checks for NULL prior to calling kfree() in security/.

    Signed-off-by: Jesper Juhl
    Acked-by: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     

31 Oct, 2005

1 commit

  • The attached patch adds LSM hooks for key management facilities. The notable
    changes are:

    (1) The key struct now supports a security pointer for the use of security
    modules. This will permit key labelling and restrictions on which
    programs may access a key.

    (2) Security modules get a chance to note (or abort) the allocation of a key.

    (3) The key permission checking can now be enhanced by the security modules;
    the permissions check consults LSM if all other checks bear out.

    (4) The key permissions checking functions now return an error code rather
    than a boolean value.

    (5) An extra permission has been added to govern the modification of
    attributes (UID, GID, permissions).

    Note that there isn't an LSM hook specifically for each keyctl() operation,
    but rather the permissions hook allows control of individual operations based
    on the permission request bits.

    Key management access control through LSM is enabled by automatically if both
    CONFIG_KEYS and CONFIG_SECURITY are enabled.

    This should be applied on top of the patch ensubjected:

    [PATCH] Keys: Possessor permissions should be additive

    Signed-Off-By: David Howells
    Signed-off-by: Chris Wright
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

29 Sep, 2005

1 commit

  • The attached patch adds extra permission grants to keys for the possessor of a
    key in addition to the owner, group and other permissions bits. This makes
    SUID binaries easier to support without going as far as labelling keys and key
    targets using the LSM facilities.

    This patch adds a second "pointer type" to key structures (struct key_ref *)
    that can have the bottom bit of the address set to indicate the possession of
    a key. This is propagated through searches from the keyring to the discovered
    key. It has been made a separate type so that the compiler can spot attempts
    to dereference a potentially incorrect pointer.

    The "possession" attribute can't be attached to a key structure directly as
    it's not an intrinsic property of a key.

    Pointers to keys have been replaced with struct key_ref *'s wherever
    possession information needs to be passed through.

    This does assume that the bottom bit of the pointer will always be zero on
    return from kmem_cache_alloc().

    The key reference type has been made into a typedef so that at least it can be
    located in the sources, even though it's basically a pointer to an undefined
    type. I've also renamed the accessor functions to be more useful, and all
    reference variables should now end in "_ref".

    Signed-Off-By: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

26 Jun, 2005

1 commit

  • 2.6.12-rc6-mm1 has a few remaining synchronize_kernel()s, some (but not
    all) in comments. This patch changes these synchronize_kernel() calls (and
    comments) to synchronize_rcu() or synchronize_sched() as follows:

    - arch/x86_64/kernel/mce.c mce_read(): change to synchronize_sched() to
    handle races with machine-check exceptions (synchronize_rcu() would not cut
    it given RCU implementations intended for hardcore realtime use.

    - drivers/input/serio/i8042.c i8042_stop(): change to synchronize_sched() to
    handle races with i8042_interrupt() interrupt handler. Again,
    synchronize_rcu() would not cut it given RCU implementations intended for
    hardcore realtime use.

    - include/*/kdebug.h comments: change to synchronize_sched() to handle races
    with NMIs. As before, synchronize_rcu() would not cut it...

    - include/linux/list.h comment: change to synchronize_rcu(), since this
    comment is for list_del_rcu().

    - security/keys/key.c unregister_key_type(): change to synchronize_rcu(),
    since this is interacting with RCU read side.

    - security/keys/process_keys.c install_session_keyring(): change to
    synchronize_rcu(), since this is interacting with RCU read side.

    Signed-off-by: "Paul E. McKenney"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

24 Jun, 2005

2 commits

  • The attached patch makes the following changes:

    (1) There's a new special key type called ".request_key_auth".

    This is an authorisation key for when one process requests a key and
    another process is started to construct it. This type of key cannot be
    created by the user; nor can it be requested by kernel services.

    Authorisation keys hold two references:

    (a) Each refers to a key being constructed. When the key being
    constructed is instantiated the authorisation key is revoked,
    rendering it of no further use.

    (b) The "authorising process". This is either:

    (i) the process that called request_key(), or:

    (ii) if the process that called request_key() itself had an
    authorisation key in its session keyring, then the authorising
    process referred to by that authorisation key will also be
    referred to by the new authorisation key.

    This means that the process that initiated a chain of key requests
    will authorise the lot of them, and will, by default, wind up with
    the keys obtained from them in its keyrings.

    (2) request_key() creates an authorisation key which is then passed to
    /sbin/request-key in as part of a new session keyring.

    (3) When request_key() is searching for a key to hand back to the caller, if
    it comes across an authorisation key in the session keyring of the
    calling process, it will also search the keyrings of the process
    specified therein and it will use the specified process's credentials
    (fsuid, fsgid, groups) to do that rather than the calling process's
    credentials.

    This allows a process started by /sbin/request-key to find keys belonging
    to the authorising process.

    (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
    direct read or search permission if that key is contained within the
    keyrings of a process specified by an authorisation key found within the
    calling process's session keyring, and is searchable using the
    credentials of the authorising process.

    This allows a process started by /sbin/request-key to read keys belonging
    to the authorising process.

    (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
    KEYCTL_NEGATE will specify a keyring of the authorising process, rather
    than the process doing the instantiation.

    (6) One of the process keyrings can be nominated as the default to which
    request_key() should attach new keys if not otherwise specified. This is
    done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
    constants. The current setting can also be read using this call.

    (7) request_key() is partially interruptible. If it is waiting for another
    process to finish constructing a key, it can be interrupted. This permits
    a request-key cycle to be broken without recourse to rebooting.

    Signed-Off-By: David Howells
    Signed-Off-By: Benoit Boissinot
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • The attached patch changes the key implementation in a number of ways:

    (1) It removes the spinlock from the key structure.

    (2) The key flags are now accessed using atomic bitops instead of
    write-locking the key spinlock and using C bitwise operators.

    The three instantiation flags are dealt with with the construction
    semaphore held during the request_key/instantiate/negate sequence, thus
    rendering the spinlock superfluous.

    The key flags are also now bit numbers not bit masks.

    (3) The key payload is now accessed using RCU. This permits the recursive
    keyring search algorithm to be simplified greatly since no locks need be
    taken other than the usual RCU preemption disablement. Searching now does
    not require any locks or semaphores to be held; merely that the starting
    keyring be pinned.

    (4) The keyring payload now includes an RCU head so that it can be disposed
    of by call_rcu(). This requires that the payload be copied on unlink to
    prevent introducing races in copy-down vs search-up.

    (5) The user key payload is now a structure with the data following it. It
    includes an RCU head like the keyring payload and for the same reason. It
    also contains a data length because the data length in the key may be
    changed on another CPU whilst an RCU protected read is in progress on the
    payload. This would then see the supposed RCU payload and the on-key data
    length getting out of sync.

    I'm tempted to drop the key's datalen entirely, except that it's used in
    conjunction with quota management and so is a little tricky to get rid
    of.

    (6) Update the keys documentation.

    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds