From: Paul Moore <paul@paul-moore.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: selinux@vger.kernel.org, Stephen Smalley <sds@tycho.nsa.gov>,
Michal Sekletar <msekleta@redhat.com>
Subject: Re: [PATCH] selinux: optimize MLS context to string conversion
Date: Tue, 30 Jul 2019 10:46:34 -0400 [thread overview]
Message-ID: <CAHC9VhTetPBY9keC5ps=XHvgzLOeZE7rDbeG00R4jz0mYaduhA@mail.gmail.com> (raw)
In-Reply-To: <20190730124852.7670-1-omosnace@redhat.com>
On Tue, Jul 30, 2019 at 8:48 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> When mls_compute_context_len() or mls_sid_to_context() encounters a
> context with large category ranges, it behaves suboptimally - it
> traverses each positive bit of the category bitmap, each time calling
> find_next_bit() again.
>
> This has a large performance impact on UNIX datagram sockets with
> SO_PASSSEC set, since here the peer context needs to be converted to
> string for each recieved datagram. See [1] for more information.
>
> This patch introduces a new helper for ebitmap traversal, which allows
> to efficiently iterate over positive ranges instead of bits -
> ebitmap_for_each_positive_range() - and converts the two mls_*()
> functions to leverage it.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1733259
>
> Reported-by: Michal Sekletar <msekleta@redhat.com>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
My current opinion is that this isn't the right way to solve the
problem, a SELinux sid->secctx cache would be a better choice. With
that in mind, and the understanding that this patch is an optimization
and not a bug fix, I'm going to hold-off on doing anything with this
patch until there is a cache option we can use for comparison.
As Stephen mentioned in the RH BZ (linked in the description), there
are a couple of reasons why the code doesn't currently store the
string translations. Ignoring the issue of aliasing for a moment, I
do want to stress that I agree with Stephen on the issue of memory
pressure and that to keep translated strings around indefinitely in
the kernel is going to be a problem (there are other issues beyond
just memory use). I imagine any cache implementation would need to be
built to only store a subset of all the translations and there would
need to be a way to age-out those translations (as well as purge them
completely on events such as a policy load).
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2019-07-30 14:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 12:48 [PATCH] selinux: optimize MLS context to string conversion Ondrej Mosnacek
2019-07-30 14:46 ` Paul Moore [this message]
2019-07-30 16:35 ` Casey Schaufler
2019-09-16 14:43 ` Stephen Smalley
2019-09-16 17:30 ` Stephen Smalley
2019-09-17 10:23 ` Ondrej Mosnacek
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='CAHC9VhTetPBY9keC5ps=XHvgzLOeZE7rDbeG00R4jz0mYaduhA@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=msekleta@redhat.com \
--cc=omosnace@redhat.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
/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.