Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 4月, 2012 2 次提交
    • E
      LSM: shrink the common_audit_data data union · 48c62af6
      由 Eric Paris 提交于 
      After shrinking the common_audit_data stack usage for private LSM data I'm
not going to shrink the data union.  To do this I'm going to move anything
larger than 2 void * ptrs to it's own structure and require it to be declared
separately on the calling stack.  Thus hot paths which don't need more than
a couple pointer don't have to declare space to hold large unneeded
structures.  I could get this down to one void * by dealing with the key
struct and the struct path.  We'll see if that is helpful after taking care of
networking.
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48c62af6
    • E
      LSM: shrink sizeof LSM specific portion of common_audit_data · 3b3b0e4f
      由 Eric Paris 提交于 
      Linus found that the gigantic size of the common audit data caused a big
perf hit on something as simple as running stat() in a loop.  This patch
requires LSMs to declare the LSM specific portion separately rather than
doing it in a union.  Thus each LSM can be responsible for shrinking their
portion and don't have to pay a penalty just because other LSMs have a
bigger space requirement.
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b3b0e4f
  3. 01 4月, 2012 1 次提交
  5. 20 2月, 2012 1 次提交
    • D
      Replace the fd_sets in struct fdtable with an array of unsigned longs · 1fd36adc
      由 David Howells 提交于 
      Replace the fd_sets in struct fdtable with an array of unsigned longs and then
use the standard non-atomic bit operations rather than the FD_* macros.

This:

 (1) Removes the abuses of struct fd_set:

     (a) Since we don't want to allocate a full fd_set the vast majority of the
     	 time, we actually, in effect, just allocate a just-big-enough array of
     	 unsigned longs and cast it to an fd_set type - so why bother with the
     	 fd_set at all?

     (b) Some places outside of the core fdtable handling code (such as
     	 SELinux) want to look inside the array of unsigned longs hidden inside
     	 the fd_set struct for more efficient iteration over the entire set.

 (2) Eliminates the use of FD_*() macros in the kernel completely.

 (3) Permits the __FD_*() macros to be deleted entirely where not exposed to
     userspace.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Link: http://lkml.kernel.org/r/20120216174954.23314.48147.stgit@warthog.procyon.org.ukSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
      1fd36adc
  7. 14 2月, 2012 1 次提交
  9. 07 1月, 2012 1 次提交
  11. 06 1月, 2012 7 次提交
  13. 04 1月, 2012 4 次提交
  15. 07 12月, 2011 1 次提交
  17. 04 12月, 2011 1 次提交
  19. 23 11月, 2011 1 次提交
  21. 01 11月, 2011 1 次提交
  23. 10 9月, 2011 4 次提交
  25. 02 8月, 2011 2 次提交
  27. 27 7月, 2011 1 次提交
  29. 20 7月, 2011 2 次提交
  31. 23 6月, 2011 1 次提交
  33. 09 6月, 2011 1 次提交
    • L
      selinux: simplify and clean up inode_has_perm() · 95f4efb2
      由 Linus Torvalds 提交于 
      This is a rather hot function that is called with a potentially NULL
"struct common_audit_data" pointer argument.  And in that case it has to
provide and initialize its own dummy common_audit_data structure.

However, all the _common_ cases already pass it a real audit-data
structure, so that uncommon NULL case not only creates a silly run-time
test, more importantly it causes that function to have a big stack frame
for the dummy variable that isn't even used in the common case!

So get rid of that stupid run-time behavior, and make the (few)
functions that currently call with a NULL pointer just call a new helper
function instead (naturally called inode_has_perm_noapd(), since it has
no adp argument).

This makes the run-time test be a static code generation issue instead,
and allows for a much denser stack since none of the common callers need
the dummy structure.  And a denser stack not only means less stack space
usage, it means better cache behavior.  So we have a win-win-win from
this simplification: less code executed, smaller stack footprint, and
better cache behavior.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      95f4efb2
  35. 29 4月, 2011 3 次提交
    • E
      SELinux: pass last path component in may_create · cb1e922f
      由 Eric Paris 提交于 
      New inodes are created in a two stage process.  We first will compute the
label on a new inode in security_inode_create() and check if the
operation is allowed.  We will then actually re-compute that same label and
apply it in security_inode_init_security().  The change to do new label
calculations based in part on the last component of the path name only
passed the path component information all the way down the
security_inode_init_security hook.  Down the security_inode_create hook the
path information did not make it past may_create.  Thus the two calculations
came up differently and the permissions check might not actually be against
the label that is created.  Pass and use the same information in both places
to harmonize the calculations and checks.
Reported-by: NDominick Grift <domg472@gmail.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      cb1e922f
    • E
      SELinux: introduce path_has_perm · 2875fa00
      由 Eric Paris 提交于 
      We currently have inode_has_perm and dentry_has_perm.  dentry_has_perm just
calls inode_has_perm with additional audit data.  But dentry_has_perm can
take either a dentry or a path.  Split those to make the code obvious and
to fix the previous problem where I thought dentry_has_perm always had a
valid dentry and mnt.
Signed-off-by: NEric Paris <eparis@redhat.com>
      2875fa00
    • E
      SELinux: pass last path component in may_create · 562abf62
      由 Eric Paris 提交于 
      New inodes are created in a two stage process.  We first will compute the
label on a new inode in security_inode_create() and check if the
operation is allowed.  We will then actually re-compute that same label and
apply it in security_inode_init_security().  The change to do new label
calculations based in part on the last component of the path name only
passed the path component information all the way down the
security_inode_init_security hook.  Down the security_inode_create hook the
path information did not make it past may_create.  Thus the two calculations
came up differently and the permissions check might not actually be against
the label that is created.  Pass and use the same information in both places
to harmonize the calculations and checks.
Reported-by: NDominick Grift <domg472@gmail.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      562abf62
  37. 26 4月, 2011 4 次提交
  39. 25 4月, 2011 1 次提交
    • A
      SECURITY: Move exec_permission RCU checks into security modules · 1c990429
      由 Andi Kleen 提交于 
      Right now all RCU walks fall back to reference walk when CONFIG_SECURITY
is enabled, even though just the standard capability module is active.
This is because security_inode_exec_permission unconditionally fails
RCU walks.

Move this decision to the low level security module. This requires
passing the RCU flags down the security hook. This way at least
the capability module and a few easy cases in selinux/smack work
with RCU walks with CONFIG_SECURITY=y
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      1c990429