linux-kernel - Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 16 Oct 2008 08:10:03 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Kentaro Takeda <takedakn@...data.co.jp>
Cc:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	serue@...ibm.com, sds@...ho.nsa.gov, jmorris@...ei.org,
	chrisw@...s-sol.org, dhowells@...hat.com,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, haradats@...data.co.jp,
	akpm@...ux-foundation.org
Subject: Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.

On Thu, Oct 16, 2008 at 01:05:34PM +0900, Kentaro Takeda wrote:
> Paul E. McKenney wrote:
> > A few comments below -- some rcu_dereference()s are needed.
>
> This list doesn't use RCU since it is for Write-Once-Read-Many 
> situation (i.e. no-update and no-delete). TOMOYO Linux uses this list 
> for storing policy elements. Most of elements are allocated when the 
> kernel is loaded, and they are referred during lifetime of the kernel.
> 
> Since read_lock is not needed when referring this list, code of 
> TOMOYO keeps its simplicity. If TOMOYO used RCU or reader/writer lock,
> the code would be a jumble of read_lock and it would be almost 
> impossible to maintain and review the code... X-p This is the reason 
> why TOMOYO uses this WORM list.
> 
> Though size of policy increases with learning mode, the same 
> pathnames once learned will be reused. So memory usage of TOMOYO 
> doesn't increase infinitely; if still worried, we can set memory 
> quota.
> 
> > The general idea looks sound, at least as long as the lists remain
> > short.  Otherwise, the list scan in list1_add_tail_mb() will take
> > too long.
>
> Typically less than 100. The length of list won't matter since the 
> frequency of append is very low.

That sounds small enough to me.  If it becomes a problem some time in
the future, it will be easy for you to add a tail pointer or some such.

> Paul, would you review this list from the perspective of WORM list?

Hmmm...  I thought I was reviewing it from that perspective.  You never
delete anything from the list, so you don't need RCU.

But fair enough.  How about the following?

	#define worm_dereference()	rcu_dereference()
	#define worm_assign_pointer()	rcu_assign_pointer()

Then put worm_dereference() where I told you to put rcu_dereference()
and also put worm_assign_pointer() where I suggested using
rcu_assign_pointer().

You might not be using RCU, but keep in mind that RCU is primarily about
-removing- items from a data structure.  When you -insert- items into
a data structure that is being concurrently read, as you are doing, you
must solve all the same problems that RCU has to solve for list insertion.
Please see http://lkml.org/lkml/2008/2/2/255 for examples showing why
this is needed.  This posting does indeed use RCU terminology, but it is
focused only on insertion, and therefore exactly describes the situation
that you are in.

I am sure that you will get back to me with any questions or objections
that you might have after looking this over.  ;-)

							Thanx, Paul
--
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/