Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 9月, 2011 16 次提交
  3. 23 8月, 2011 7 次提交
    • D
      KEYS: Correctly destroy key payloads when their keytype is removed · 0c061b57
      由 David Howells 提交于 
      unregister_key_type() has code to mark a key as dead and make it unavailable in
one loop and then destroy all those unavailable key payloads in the next loop.
However, the loop to mark keys dead renders the key undetectable to the second
loop by changing the key type pointer also.

Fix this by the following means:

 (1) The key code has two garbage collectors: one deletes unreferenced keys and
     the other alters keyrings to delete links to old dead, revoked and expired
     keys.  They can end up holding each other up as both want to scan the key
     serial tree under spinlock.  Combine these into a single routine.

 (2) Move the dead key marking, dead link removal and dead key removal into the
     garbage collector as a three phase process running over the three cycles
     of the normal garbage collection procedure.  This is tracked by the
     KEY_GC_REAPING_DEAD_1, _2 and _3 state flags.

     unregister_key_type() then just unlinks the key type from the list, wakes
     up the garbage collector and waits for the third phase to complete.

 (3) Downgrade the key types sem in unregister_key_type() once it has deleted
     the key type from the list so that it doesn't block the keyctl() syscall.

 (4) Dead keys that cannot be simply removed in the third phase have their
     payloads destroyed with the key's semaphore write-locked to prevent
     interference by the keyctl() syscall.  There should be no in-kernel users
     of dead keys of that type by the point of unregistration, though keyctl()
     may be holding a reference.

 (5) Only perform timer recalculation in the GC if the timer actually expired.
     If it didn't, we'll get another cycle when it goes off - and if the key
     that actually triggered it has been removed, it's not a problem.

 (6) Only garbage collect link if the timer expired or if we're doing dead key
     clean up phase 2.

 (7) As only key_garbage_collector() is permitted to use rb_erase() on the key
     serial tree, it doesn't need to revalidate its cursor after dropping the
     spinlock as the node the cursor points to must still exist in the tree.

 (8) Drop the spinlock in the GC if there is contention on it or if we need to
     reschedule.  After dealing with that, get the spinlock again and resume
     scanning.

This has been tested in the following ways:

 (1) Run the keyutils testsuite against it.

 (2) Using the AF_RXRPC and RxKAD modules to test keytype removal:

     Load the rxrpc_s key type:

	# insmod /tmp/af-rxrpc.ko
	# insmod /tmp/rxkad.ko

     Create a key (http://people.redhat.com/~dhowells/rxrpc/listen.c):

	# /tmp/listen &
	[1] 8173

     Find the key:

	# grep rxrpc_s /proc/keys
	091086e1 I--Q--     1 perm 39390000     0     0 rxrpc_s   52:2

     Link it to a session keyring, preferably one with a higher serial number:

	# keyctl link 0x20e36251 @s

     Kill the process (the key should remain as it's linked to another place):

	# fg
	/tmp/listen
	^C

     Remove the key type:

	rmmod rxkad
	rmmod af-rxrpc

     This can be made a more effective test by altering the following part of
     the patch:

	if (unlikely(gc_state & KEY_GC_REAPING_DEAD_2)) {
		/* Make sure everyone revalidates their keys if we marked a
		 * bunch as being dead and make sure all keyring ex-payloads
		 * are destroyed.
		 */
		kdebug("dead sync");
		synchronize_rcu();

     To call synchronize_rcu() in GC phase 1 instead.  That causes that the
     keyring's old payload content to hang around longer until it's RCU
     destroyed - which usually happens after GC phase 3 is complete.  This
     allows the destroy_dead_key branch to be tested.
Reported-by: NBenjamin Coddington <bcodding@gmail.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      0c061b57
    • D
      KEYS: The dead key link reaper should be non-reentrant · d199798b
      由 David Howells 提交于 
      The dead key link reaper should be non-reentrant as it relies on global state
to keep track of where it's got to when it returns to the work queue manager to
give it some air.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      d199798b
    • D
      KEYS: Make the key reaper non-reentrant · b072e9bc
      由 David Howells 提交于 
      Make the key reaper non-reentrant by sticking it on the appropriate system work
queue when we queue it.  This will allow it to have global state and drop
locks.  It should probably be non-reentrant already as it may spend a long time
holding the key serial spinlock, and so multiple entrants can spend long
periods of time just sitting there spinning, waiting to get the lock.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      b072e9bc
    • D
      KEYS: Move the unreferenced key reaper to the keys garbage collector file · 8bc16dea
      由 David Howells 提交于 
      Move the unreferenced key reaper function to the keys garbage collector file
as that's a more appropriate place with the dead key link reaper.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      8bc16dea
    • D
      KEYS: __key_link() should use the RCU deref wrapper for keyring payloads · 6d528b08
      由 David Howells 提交于 
      __key_link() should use the RCU deref wrapper rcu_dereference_locked_keyring()
for accessing keyring payloads rather than calling rcu_dereference_protected()
directly.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      6d528b08
    • D
      KEYS: keyctl_get_keyring_ID() should create a session keyring if create flag set · 3ecf1b4f
      由 David Howells 提交于 
      The keyctl call:

	keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1)

should create a session keyring if the process doesn't have one of its own
because the create flag argument is set - rather than subscribing to and
returning the user-session keyring as:

	keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0)

will do.

This can be tested by commenting out pam_keyinit in the /etc/pam.d files and
running the following program a couple of times in a row:

	#include <stdio.h>
	#include <stdlib.h>
	#include <keyutils.h>
	int main(int argc, char *argv[])
	{
		key_serial_t uk, usk, sk, nsk;
		uk  = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);
		usk = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);
		sk  = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0);
		nsk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1);
		printf("keys: %08x %08x %08x %08x\n", uk, usk, sk, nsk);
		return 0;
	}

Without this patch, I see:

	keys: 3975ddc7 119c0c66 119c0c66 119c0c66
	keys: 3975ddc7 119c0c66 119c0c66 119c0c66

With this patch, I see:

	keys: 2cb4997b 34112878 34112878 17db2ce3
	keys: 2cb4997b 34112878 34112878 39f3c73e

As can be seen, the session keyring starts off the same as the user-session
keyring each time, but with the patch a new session keyring is created when
the create flag is set.
Reported-by: NGreg Wettstein <greg@enjellic.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NGreg Wettstein <greg@enjellic.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      3ecf1b4f
    • D
      KEYS: If install_session_keyring() is given a keyring, it should install it · 99599537
      由 David Howells 提交于 
      If install_session_keyring() is given a keyring, it should install it rather
than just creating a new one anyway.  This was accidentally broken in:

	commit d84f4f99
	Author: David Howells <dhowells@redhat.com>
	Date:   Fri Nov 14 10:39:23 2008 +1100
	Subject: CRED: Inaugurate COW credentials

The impact of that commit is that pam_keyinit no longer works correctly if
'force' isn't specified against a login process. This is because:

	keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0)

now always creates a new session keyring and thus the check whether the session
keyring and the user-session keyring are the same is always false.  This leads
pam_keyinit to conclude that a session keyring is installed and it shouldn't be
revoked by pam_keyinit here if 'revoke' is specified.

Any system that specifies 'force' against pam_keyinit in the PAM configuration
files for login methods (login, ssh, su -l, kdm, etc.) is not affected since
that bypasses the broken check and forces the creation of a new session keyring
anyway (for which the revoke flag is not cleared) - and any subsequent call to
pam_keyinit really does have a session keyring already installed, and so the
check works correctly there.

Reverting to the previous behaviour will cause the kernel to subscribe the
process to the user-session keyring as its session keyring if it doesn't have a
session keyring of its own.  pam_keyinit will detect this and install a new
session keyring anyway (and won't clear the revert flag).

This can be tested by commenting out pam_keyinit in the /etc/pam.d files and
running the following program a couple of times in a row:

	#include <stdio.h>
	#include <stdlib.h>
	#include <keyutils.h>
	int main(int argc, char *argv[])
	{
		key_serial_t uk, usk, sk;
		uk = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);
		usk = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);
		sk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0);
		printf("keys: %08x %08x %08x\n", uk, usk, sk);
		return 0;
	}

Without the patch, I see:

	keys: 3884e281 24c4dfcf 22825f8e
	keys: 3884e281 24c4dfcf 068772be

With the patch, I see:

	keys: 26be9c83 0e755ce0 0e755ce0
	keys: 26be9c83 0e755ce0 0e755ce0

As can be seen, with the patch, the session keyring is the same as the
user-session keyring each time; without the patch a new session keyring is
generated each time.
Reported-by: NGreg Wettstein <greg@enjellic.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: NGreg Wettstein <greg@enjellic.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      99599537
  5. 18 8月, 2011 1 次提交
    • M
      evm: add Kconfig TCG_TPM dependency · dbe5ad17
      由 Mimi Zohar 提交于 
      Although the EVM encrypted-key should be encrypted/decrypted using a
trusted-key, a user-defined key could be used instead. When using a user-
defined key, a TCG_TPM dependency should not be required.  Unfortunately,
the encrypted-key code needs to be refactored a bit in order to remove
this dependency.

This patch adds the TCG_TPM dependency.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>,
	     Randy Dunlap <rdunlap@xenotimenet>
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      dbe5ad17
  7. 17 8月, 2011 1 次提交
  9. 16 8月, 2011 1 次提交
  11. 12 8月, 2011 1 次提交
    • Z
      capabilities: do not grant full privs for setuid w/ file caps + no effective caps · 4d49f671
      由 Zhi Li 提交于 
      A task (when !SECURE_NOROOT) which executes a setuid-root binary will
obtain root privileges while executing that binary.  If the binary also
has effective capabilities set, then only those capabilities will be
granted.  The rationale is that the same binary can carry both setuid-root
and the minimal file capability set, so that on a filesystem not
supporting file caps the binary can still be executed with privilege,
while on a filesystem supporting file caps it will run with minimal
privilege.

This special case currently does NOT happen if there are file capabilities
but no effective capabilities.  Since capability-aware programs can very
well start with empty pE but populated pP and move those caps to pE when
needed.  In other words, if the file has file capabilities but NOT
effective capabilities, then we should do the same thing as if there
were file capabilities, and not grant full root privileges.

This patchset does that.

(Changelog by Serge Hallyn).
Signed-off-by: NZhi Li <lizhi1215@gmail.com>
Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
      4d49f671
  13. 11 8月, 2011 1 次提交
  15. 09 8月, 2011 1 次提交
  17. 02 8月, 2011 2 次提交
  19. 27 7月, 2011 2 次提交
  21. 24 7月, 2011 1 次提交
    • T
      VFS : mount lock scalability for internal mounts · 423e0ab0
      由 Tim Chen 提交于 
      For a number of file systems that don't have a mount point (e.g. sockfs
and pipefs), they are not marked as long term. Therefore in
mntput_no_expire, all locks in vfs_mount lock are taken instead of just
local cpu's lock to aggregate reference counts when we release
reference to file objects.  In fact, only local lock need to have been
taken to update ref counts as these file systems are in no danger of
going away until we are ready to unregister them.

The attached patch marks file systems using kern_mount without
mount point as long term.  The contentions of vfs_mount lock
is now eliminated.  Before un-registering such file system,
kern_unmount should be called to remove the long term flag and
make the mount point ready to be freed.
Signed-off-by: NTim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      423e0ab0
  23. 21 7月, 2011 3 次提交
  25. 20 7月, 2011 3 次提交