1. 14 10月, 2009 1 次提交
  2. 02 9月, 2009 1 次提交
    • D
      KEYS: Add a keyctl to install a process's session keyring on its parent [try #6] · ee18d64c
      David Howells 提交于
      Add a keyctl to install a process's session keyring onto its parent.  This
      replaces the parent's session keyring.  Because the COW credential code does
      not permit one process to change another process's credentials directly, the
      change is deferred until userspace next starts executing again.  Normally this
      will be after a wait*() syscall.
      
      To support this, three new security hooks have been provided:
      cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
      the blank security creds and key_session_to_parent() - which asks the LSM if
      the process may replace its parent's session keyring.
      
      The replacement may only happen if the process has the same ownership details
      as its parent, and the process has LINK permission on the session keyring, and
      the session keyring is owned by the process, and the LSM permits it.
      
      Note that this requires alteration to each architecture's notify_resume path.
      This has been done for all arches barring blackfin, m68k* and xtensa, all of
      which need assembly alteration to support TIF_NOTIFY_RESUME.  This allows the
      replacement to be performed at the point the parent process resumes userspace
      execution.
      
      This allows the userspace AFS pioctl emulation to fully emulate newpag() and
      the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
      alter the parent process's PAG membership.  However, since kAFS doesn't use
      PAGs per se, but rather dumps the keys into the session keyring, the session
      keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
      the newpag flag.
      
      This can be tested with the following program:
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <keyutils.h>
      
      	#define KEYCTL_SESSION_TO_PARENT	18
      
      	#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
      
      	int main(int argc, char **argv)
      	{
      		key_serial_t keyring, key;
      		long ret;
      
      		keyring = keyctl_join_session_keyring(argv[1]);
      		OSERROR(keyring, "keyctl_join_session_keyring");
      
      		key = add_key("user", "a", "b", 1, keyring);
      		OSERROR(key, "add_key");
      
      		ret = keyctl(KEYCTL_SESSION_TO_PARENT);
      		OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
      
      		return 0;
      	}
      
      Compiled and linked with -lkeyutils, you should see something like:
      
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: _ses
      	355907932 --alswrv   4043    -1   \_ keyring: _uid.4043
      	[dhowells@andromeda ~]$ /tmp/newpag
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: _ses
      	1055658746 --alswrv   4043  4043   \_ user: a
      	[dhowells@andromeda ~]$ /tmp/newpag hello
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: hello
      	340417692 --alswrv   4043  4043   \_ user: a
      
      Where the test program creates a new session keyring, sticks a user key named
      'a' into it and then installs it on its parent.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      ee18d64c
  3. 24 8月, 2009 1 次提交
    • C
      sh: Improve unwind info for signals · 2fc742f8
      Carl Shaw 提交于
      GCC does not issue unwind information for function epilogues.
      Unfortunately we can catch a signal during an epilogue.  The signal
      handler writes the current context and signal return code onto the stack
      overwriting previous contents.  During unwinding, libgcc can try to
      restore registers from the stack and restores corrupted ones. This can
      lead to segmentation, misaligned access and sigbus faults.
      
      For example, consider the following code:
      
          mov.l   r12,@-r15
          mov.l   r14,@-r15
          sts.l   pr,@-r15
          mov     r15,r14
      
          <do stuff>
      
          mov r14, r15
          lds.l @r15+, pr
      	<<< SIGNAL HERE
          mov.l @r15+, r14
          mov.l @r15+, r12
          rts
      
      Unwind is aware that pr was pushed to stack in prolog, so tries to
      restore it.  Unfortunately it restores the last word of the signal
      handler code placed on the stack by the kernel.
      
      This patch tries to avoid the problem by adding a guard region on the
      stack between where the function pushes data and where the signal handler
      pushes its return code.  We probably don't see this problem often because
      exception handling unwinding in an epilogue only occurs due to a pthread
      cancel signal.  Also the kernel signal stack handler alignment of 8 bytes
      could hide the occurance of this problem sometimes as the stack may not
      be trampled at a particular required word.
      
      This is not guaranteed to always work.  It relies on a frame pointer
      existing for the function (so it can get the correct sp value) which is
      not always the case for the SH4.
      
      Modifications will also be made to libgcc for the case where there is no
      fp.
      Signed-off-by: NCarl Shaw <carl.shaw@st.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      2fc742f8
  4. 18 6月, 2009 1 次提交
    • M
      sh: Fix declaration of __kernel_sigreturn and __kernel_rt_sigreturn · 94455711
      Matt Fleming 提交于
      GCC 4.5.0 complains about the declaration of variables
      __kernel_sigreturn and __kernel_rt_sigreturn because they have type
      void.  Correctly declare these symbols as functions to fix the
      following error,
      
      arch/sh/kernel/signal_32.c: In function 'setup_frame':
      arch/sh/kernel/signal_32.c:368:14: error: taking address of expression of type 'void'
      arch/sh/kernel/signal_32.c: In function 'setup_rt_frame':
      arch/sh/kernel/signal_32.c:452:14: error: taking address of expression of type 'void'
      make[1]: *** [arch/sh/kernel/signal_32.o] Error 1
      make: *** [arch/sh/kernel] Error 2
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      94455711
  5. 29 1月, 2009 1 次提交
  6. 22 12月, 2008 1 次提交
  7. 24 9月, 2008 1 次提交
  8. 12 9月, 2008 1 次提交
  9. 08 9月, 2008 1 次提交
  10. 02 8月, 2008 1 次提交
  11. 28 7月, 2008 3 次提交
  12. 26 3月, 2008 1 次提交
  13. 28 1月, 2008 2 次提交
  14. 20 10月, 2007 1 次提交
  15. 28 9月, 2007 2 次提交
    • P
      sh: Conditionalize gUSA support. · 83662461
      Paul Mundt 提交于
      This conditionalizes gUSA support. gUSA is not supported on
      SMP configurations, and it's not necessary there anyways due
      to having other atomicity options (ie, movli.l/movco.l).
      
      Anything implementing the LL/SC semantics (all SH-4A CPUs)
      can switch to userspace atomicity implementations without
      requiring gUSA. This is left default-enabled on all UP so
      that glibc doesn't break.
      
      Those that know what they are doing can disable this explicitly.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      83662461
    • P
      sh: Tidy up gUSA preempt handling. · e5137682
      Paul Mundt 提交于
      Currently gUSA toggles hardirqs to disable preemption in the signal
      handler. Make the preemption toggling explicit, and kill off some
      CONFIG_PREEMPT ifdefs in the process.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      e5137682
  16. 19 6月, 2007 1 次提交
  17. 18 6月, 2007 1 次提交
  18. 08 6月, 2007 2 次提交
  19. 09 5月, 2007 3 次提交
  20. 05 3月, 2007 1 次提交
  21. 13 2月, 2007 1 次提交
  22. 12 12月, 2006 1 次提交
  23. 08 12月, 2006 1 次提交
  24. 06 12月, 2006 2 次提交
  25. 27 9月, 2006 3 次提交
  26. 30 8月, 2005 1 次提交
    • S
      [PATCH] convert signal handling of NODEFER to act like other Unix boxes. · 69be8f18
      Steven Rostedt 提交于
      It has been reported that the way Linux handles NODEFER for signals is
      not consistent with the way other Unix boxes handle it.  I've written a
      program to test the behavior of how this flag affects signals and had
      several reports from people who ran this on various Unix boxes,
      confirming that Linux seems to be unique on the way this is handled.
      
      The way NODEFER affects signals on other Unix boxes is as follows:
      
      1) If NODEFER is set, other signals in sa_mask are still blocked.
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal is
      still blocked. (Note: this is the behavior of all tested but Linux _and_
      NetBSD 2.0 *).
      
      The way NODEFER affects signals on Linux:
      
      1) If NODEFER is set, other signals are _not_ blocked regardless of
      sa_mask (Even NetBSD doesn't do this).
      
      2) If NODEFER is set and the signal is in sa_mask, then the signal being
      handled is not blocked.
      
      The patch converts signal handling in all current Linux architectures to
      the way most Unix boxes work.
      
      Unix boxes that were tested:  DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
      3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.
      
      * NetBSD was the only other Unix to behave like Linux on point #2. The
      main concern was brought up by point #1 which even NetBSD isn't like
      Linux.  So with this patch, we leave NetBSD as the lonely one that
      behaves differently here with #2.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      69be8f18
  27. 28 7月, 2005 1 次提交
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4