1. 17 Aug, 2017 1 commit
  2. 09 Jun, 2017 1 commit
  3. 01 Aug, 2014 1 commit
  4. 25 Jul, 2013 2 commits
    • Waiman Long's avatar
      SELinux: Increase ebitmap_node size for 64-bit configuration · a767f680
      Waiman Long authored
      Currently, the ebitmap_node structure has a fixed size of 32 bytes. On
      a 32-bit system, the overhead is 8 bytes, leaving 24 bytes for being
      used as bitmaps. The overhead ratio is 1/4.
      On a 64-bit system, the overhead is 16 bytes. Therefore, only 16 bytes
      are left for bitmap purpose and the overhead ratio is 1/2. With a
      3.8.2 kernel, a boot-up operation will cause the ebitmap_get_bit()
      function to be called about 9 million times. The average number of
      ebitmap_node traversal is about 3.7.
      This patch increases the size of the ebitmap_node structure to 64
      bytes for 64-bit system to keep the overhead ratio at 1/4. This may
      also improve performance a little bit by making node to node traversal
      less frequent (< 2) as more bits are available in each node.
      Signed-off-by: default avatarWaiman Long <Waiman.Long@hp.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
    • Waiman Long's avatar
      SELinux: Reduce overhead of mls_level_isvalid() function call · fee71142
      Waiman Long authored
      While running the high_systime workload of the AIM7 benchmark on
      a 2-socket 12-core Westmere x86-64 machine running 3.10-rc4 kernel
      (with HT on), it was found that a pretty sizable amount of time was
      spent in the SELinux code. Below was the perf trace of the "perf
      record -a -s" of a test run at 1500 users:
        5.04%            ls  [kernel.kallsyms]     [k] ebitmap_get_bit
        1.96%            ls  [kernel.kallsyms]     [k] mls_level_isvalid
        1.95%            ls  [kernel.kallsyms]     [k] find_next_bit
      The ebitmap_get_bit() was the hottest function in the perf-report
      output.  Both the ebitmap_get_bit() and find_next_bit() functions
      were, in fact, called by mls_level_isvalid(). As a result, the
      mls_level_isvalid() call consumed 8.95% of the total CPU time of
      all the 24 virtual CPUs which is quite a lot. The majority of the
      mls_level_isvalid() function invocations come from the socket creation
      system call.
      Looking at the mls_level_isvalid() function, it is checking to see
      if all the bits set in one of the ebitmap structure are also set in
      another one as well as the highest set bit is no bigger than the one
      specified by the given policydb data structure. It is doing it in
      a bit-by-bit manner. So if the ebitmap structure has many bits set,
      the iteration loop will be done many times.
      The current code can be rewritten to use a similar algorithm as the
      ebitmap_contains() function with an additional check for the
      highest set bit. The ebitmap_contains() function was extended to
      cover an optional additional check for the highest set bit, and the
      mls_level_isvalid() function was modified to call ebitmap_contains().
      With that change, the perf trace showed that the used CPU time drop
      down to just 0.08% (ebitmap_contains + mls_level_isvalid) of the
      total which is about 100X less than before.
        0.07%            ls  [kernel.kallsyms]     [k] ebitmap_contains
        0.05%            ls  [kernel.kallsyms]     [k] ebitmap_get_bit
        0.01%            ls  [kernel.kallsyms]     [k] mls_level_isvalid
        0.01%            ls  [kernel.kallsyms]     [k] find_next_bit
      The remaining ebitmap_get_bit() and find_next_bit() functions calls
      are made by other kernel routines as the new mls_level_isvalid()
      function will not call them anymore.
      This patch also improves the high_systime AIM7 benchmark result,
      though the improvement is not as impressive as is suggested by the
      reduction in CPU time spent in the ebitmap functions. The table below
      shows the performance change on the 2-socket x86-64 system (with HT
      on) mentioned above.
      |   Workload   | mean % change | mean % change  | mean % change   |
      |              | 10-100 users  | 200-1000 users | 1100-2000 users |
      | high_systime |     +0.1%     |     +0.9%      |     +2.6%       |
      Signed-off-by: default avatarWaiman Long <Waiman.Long@hp.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
  5. 23 Jan, 2011 1 commit
  6. 20 Oct, 2010 1 commit
  7. 16 Oct, 2007 2 commits
    • KaiGai Kohei's avatar
      SELinux: kills warnings in Improve SELinux performance when AVC misses · 087feb98
      KaiGai Kohei authored
      This patch kills ugly warnings when the "Improve SELinux performance
      when ACV misses" patch.
      Signed-off-by: default avatarKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • KaiGai Kohei's avatar
      SELinux: improve performance when AVC misses. · 9fe79ad1
      KaiGai Kohei authored
      * We add ebitmap_for_each_positive_bit() which enables to walk on
        any positive bit on the given ebitmap, to improve its performance
        using common bit-operations defined in linux/bitops.h.
        In the previous version, this logic was implemented using a combination
        of ebitmap_for_each_bit() and ebitmap_node_get_bit(), but is was worse
        in performance aspect.
        This logic is most frequestly used to compute a new AVC entry,
        so this patch can improve SELinux performance when AVC misses are happen.
      * struct ebitmap_node is redefined as an array of "unsigned long", to get
        suitable for using find_next_bit() which is fasted than iteration of
        shift and logical operation, and to maximize memory usage allocated
        from general purpose slab.
      * Any ebitmap_for_each_bit() are repleced by the new implementation
        in ss/service.c and ss/mls.c. Some of related implementation are
        changed, however, there is no incompatibility with the previous
      * The width of any new line are less or equal than 80-chars.
      The following benchmark shows the effect of this patch, when we
      access many files which have different security context one after
      another. The number is more than /selinux/avc/cache_threshold, so
      any access always causes AVC misses.
            selinux-2.6      selinux-2.6-ebitmap
      AVG:   22.763 [s]          8.750 [s]
      STD:    0.265              0.019
      1st:   22.558 [s]          8.786 [s]
      2nd:   22.458 [s]          8.750 [s]
      3rd:   22.478 [s]          8.754 [s]
      4th:   22.724 [s]          8.745 [s]
      5th:   22.918 [s]          8.748 [s]
      6th:   22.905 [s]          8.764 [s]
      7th:   23.238 [s]          8.726 [s]
      8th:   22.822 [s]          8.729 [s]
      Signed-off-by: default avatarKaiGai Kohei <kaigai@ak.jp.nec.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  8. 03 Dec, 2006 1 commit
    • Paul Moore's avatar
      NetLabel: convert to an extensibile/sparse category bitmap · 02752760
      Paul Moore authored
      The original NetLabel category bitmap was a straight char bitmap which worked
      fine for the initial release as it only supported 240 bits due to limitations
      in the CIPSO restricted bitmap tag (tag type 0x01).  This patch converts that
      straight char bitmap into an extensibile/sparse bitmap in order to lay the
      foundation for other CIPSO tag types and protocols.
      This patch also has a nice side effect in that all of the security attributes
      passed by NetLabel into the LSM are now in a format which is in the host's
      native byte/bit ordering which makes the LSM specific code much simpler; look
      at the changes in security/selinux/ss/ebitmap.c as an example.
      Signed-off-by: default avatarPaul Moore <paul.moore@hp.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  9. 22 Sep, 2006 1 commit
    • Venkat Yekkirala's avatar
      [NetLabel]: SELinux support · 7420ed23
      Venkat Yekkirala authored
      Add NetLabel support to the SELinux LSM and modify the
      socket_post_create() LSM hook to return an error code.  The most
      significant part of this patch is the addition of NetLabel hooks into
      the following SELinux LSM hooks:
       * selinux_file_permission()
       * selinux_socket_sendmsg()
       * selinux_socket_post_create()
       * selinux_socket_sock_rcv_skb()
       * selinux_socket_getpeersec_stream()
       * selinux_socket_getpeersec_dgram()
       * selinux_sock_graft()
       * selinux_inet_conn_request()
      The basic reasoning behind this patch is that outgoing packets are
      "NetLabel'd" by labeling their socket and the NetLabel security
      attributes are checked via the additional hook in
      selinux_socket_sock_rcv_skb().  NetLabel itself is only a labeling
      mechanism, similar to filesystem extended attributes, it is up to the
      SELinux enforcement mechanism to perform the actual access checks.
      In addition to the changes outlined above this patch also includes
      some changes to the extended bitmap (ebitmap) and multi-level security
      (mls) code to import and export SELinux TE/MLS attributes into and out
      of NetLabel.
      Signed-off-by: default avatarPaul Moore <paul.moore@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 05 Sep, 2005 1 commit
    • Stephen Smalley's avatar
      [PATCH] selinux: Reduce memory use by avtab · 782ebb99
      Stephen Smalley authored
      This patch improves memory use by SELinux by both reducing the avtab node
      size and reducing the number of avtab nodes.  The memory savings are
      substantial, e.g.  on a 64-bit system after boot, James Morris reported the
      following data for the targeted and strict policies:
                  #objs  objsize   kernmem
        Before:  237888       40     9.1MB
        After:    19968       24     468KB
        Before:  571680       40   21.81MB
        After:   221052       24    5.06MB
      The improvement in memory use comes at a cost in the speed of security
      server computations of access vectors, but these computations are only
      required on AVC cache misses, and performance measurements by James Morris
      using a number of benchmarks have shown that the change does not cause any
      significant degradation.
      Note that a rebuilt policy via an updated policy toolchain
      (libsepol/checkpolicy) is required in order to gain the full benefits of
      this patch, although some memory savings benefits are immediately applied
      even to older policies (in particular, the reduction in avtab node size).
      Sources for the updated toolchain are presently available from the
      sourceforge CVS tree (http://sourceforge.net/cvs/?group_id=21266), and
      tarballs are available from http://www.flux.utah.edu/~sds.
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!