linux-kernel - Re: [bug] very high non-preempt latency in context_struct_compute

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Jun 2007 18:48:20 -0400
From:	Paul Moore <paul.moore@...com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	James Carter <jwcart2@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>,
	Karl MacMillan <kmacmillan@...talrootkit.com>,
	"Christopher J. PeBenito" <cpebenito@...sys.com>,
	Joshua Brindle <method@...icmethod.com>,
	KaiGai Kohei <kaigai@...gai.gr.jp>
Subject: Re: [bug] very high non-preempt latency in context_struct_compute_av()

On Monday 04 June 2007 5:39:00 pm Stephen Smalley wrote:
> On Mon, 2007-06-04 at 17:11 -0400, Paul Moore wrote:
> > I'm not an expert on the SELinux security server guts like the other
> > people on the To/CC line of this thread, but here are my two cents on the
> > issue above.
> >
> > From what I can tell the nasty loop that is taking so long is the actual
> > access vector lookup which determines if the subject has access to the
> > object (i.e. can user/application X access resource Y on the system). 
> > While it may be possible to optimize this code I wonder if a
> > quicker/easier solution would be to refactor the lock.  At present
> > SELinux uses a read/write spinlock to protect the policy stored in the
> > kernel with macros to take and release the lock, POLICY_{RD,WR}LOCK and
> > POLICY_{RD,WR}UNLOCK.  From personal observations as well as a quick
> > check of the code, it appears that most of the time we only want to read
> > lock the policy and not write lock the policy - a spinlock, even a
> > read/write spinlock, seems a bit expensive here.
> >
> > If we were to convert from a read/write spinlock to a RCU locking
> > mechanism would this solve the preemption problem (I'm not a lock expert
> > either)?  If so, can anyone think of any reasons why converting the
> > policy lock to RCU is a bad idea (James, Stephen, the other James)?
>
> rcu_read_lock disables preemption in mainline (see rcupdate.h).
> Conversion to RCU is also complicated by conditional policy support
> (changing of policy boolean states via selinuxfs).  However, there were
> experimental patches to do that a while ago by KaiGai Kohei.

Okay, for some reason I thought someone had found a way to make 
RCU "preemptable" through the real-time work, maybe I'm just confused 
again :)  Regardless, it looks like there are better solutions possible.

Thanks.

-- 
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/