linux-kernel - Re: Make RCU dcache work with CONFIG

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:	Fri, 22 Apr 2011 09:40:48 +0800
From:	Shaohua Li <shaohua.li@...el.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"npiggin@...nel.dk" <npiggin@...nel.dk>,
	"sds@...ho.nsa.gov" <sds@...ho.nsa.gov>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>
Subject: Re: Make RCU dcache work with CONFIG_SECURITY=y

On Fri, 2011-04-22 at 08:23 +0800, Andi Kleen wrote:
> We found that all .38+ kernels with CONFIG_SECURITY just enables -- but
> not even any security module active -- are slower than .37. And also
> they don't really scale on larger machines. CONFIG_SECURITY
> is a quite common configuration, so this was seen multiple times.
> 
> The problem is that with CONFIG_SECURITY every directory permission
> check will drop out of the RCU walk and redo a bunch of work
> (and not scale of course), just in case the security module
> cannot handle it.
> 
> This patchkit tries to address this. First it moves the check for 
> RCU walks into the low level security module, so for the 
> CONFIG_SECURITY=y selinux=0 at runtime case you always get full
> performance. This is an independent patch.
> 
> Then it turned out that the two security modules who use the
> inode_exec_permission hook that impacts dcache walking -- SMACK
> and selinux -- already use RCU internally. So I added two
> followon patches that make them not drop out of the RCU walk,
> as long as they stay in their RCU "fast" path. For selinux
> this means a cache hit only and no audit event. For smack
> it means any check as long as auditing is disabled.
> 
> I didn't find good test suites for the security modules, so
> there wasn't a lot of testing on this unfortunately
> (the selinux one for LTP doesn't seem to work). Some close
> review of these changes is needed.
> 
> On the other hand the VFS changes itself are very straight forward
> and the 1/1 patch is very straight forward (and a win in itself)
> 
> The bottom line is with this patchkit a CONFIG_SECURITY=y
> kernel has as good VFS performance as a kernel with CONFIG_SECURITY
> disabled.
Great! This fully recovers the dbench regression I reported back:
http://marc.info/?l=linux-fsdevel&m=129591574123544&w=2
and we get a better throughput than 2.6.37

Thanks,
Shaohua


--
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/