All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul@paul-moore.com>
Cc: SMACK-discuss@lists.01.org,
	linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/3] Smack: Use the netlbl incoming cache
Date: Thu, 13 Aug 2020 17:32:12 -0700	[thread overview]
Message-ID: <b1fcf225-83f4-dbed-8d70-f2e0194e70db@schaufler-ca.com> (raw)
In-Reply-To: <fba5a257-599f-b2e5-d4bf-57269fc7734b@schaufler-ca.com>

On 8/13/2020 9:36 AM, Casey Schaufler wrote:
> On 8/11/2020 7:10 PM, Paul Moore wrote:
>> On Tue, Aug 11, 2020 at 8:39 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> Update the Smack security module to use the Netlabel cache
>>> mechanism to speed the processing of incoming labeled packets.
>>> There is some refactoring of the existing code that makes it
>>> simpler, and reduces duplication. The outbound packet labeling
>>> is also optimized to track the labeling state of the socket.
>>> Prior to this the socket label was redundantly set on each
>>> packet send.
>>>
>>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>>> ---
>>>  security/smack/smack.h        |  19 ++--
>>>  security/smack/smack_access.c |  55 ++++++----
>>>  security/smack/smack_lsm.c    | 245 ++++++++++++++++++++++++------------------
>>>  security/smack/smackfs.c      |  23 ++--
>>>  4 files changed, 193 insertions(+), 149 deletions(-)
>> FWIW, I gave this a cursory look just now and the NetLabel usage
>> seemed reasonable.  Out of curiosity, have you done any before/after
>> performance tests?
> It's early in the benchmark process, but TCP looks to be about 6% better.
> UDP numbers should be better. I'm not expecting the level of improvement
> SELinux saw because the label mapping from CIPSO isn't as sophisticated
> for Smack as it is for SELinux.

UDP looks like a 12% improvement, which I had expected.
On the whole, worth the effort.


  reply	other threads:[~2020-08-14  0:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200812003943.3036-1-casey.ref@schaufler-ca.com>
2020-08-12  0:39 ` [PATCH 0/3] Smack: Use the netlbl incoming cache Casey Schaufler
2020-08-12  0:39   ` [PATCH 1/3] Smack: Consolidate uses of secmark into a function Casey Schaufler
2020-08-12  0:39   ` [PATCH 2/3] Smack: Set socket labels only once Casey Schaufler
2020-08-12  0:39   ` [PATCH 3/3] Smack: Use the netlabel cache Casey Schaufler
2020-08-12  2:10   ` [PATCH 0/3] Smack: Use the netlbl incoming cache Paul Moore
2020-08-13 16:36     ` Casey Schaufler
2020-08-14  0:32       ` Casey Schaufler [this message]
2020-08-14  2:03         ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1fcf225-83f4-dbed-8d70-f2e0194e70db@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=SMACK-discuss@lists.01.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.