linux-kernel - 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-next>] [day] [month] [year] [list]

Message-Id: <1303431801-10540-1-git-send-email-andi@firstfloor.org>
Date:	Thu, 21 Apr 2011 17:23:18 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	linux-fsdevel@...r.kernel.org
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, npiggin@...nel.dk,
	shaohua.li@...el.com, sds@...ho.nsa.gov, jmorris@...ei.org,
	linux-security-module@...r.kernel.org
Subject: Make RCU dcache work with CONFIG_SECURITY=y

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.

-Andi

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