linux-kernel - Re: Stupid VFS name lookup interface..

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]

Message-ID: <CACLa4ptBVHwrruB-WeVKfPYoyAVH6ys4bEHhHTp6RyhqAw0vHg@mail.gmail.com>
Date:	Wed, 29 May 2013 18:28:23 -0700
From:	Eric Paris <eparis@...isplace.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	James Morris <jmorris@...ei.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Eric Paris <eparis@...hat.com>,
	James Morris <james.l.morris@...cle.com>
Subject: Re: Stupid VFS name lookup interface..

On Sat, May 25, 2013 at 10:19 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Sat, May 25, 2013 at 10:04 PM, James Morris <jmorris@...ei.org> wrote:
>> On Sat, 25 May 2013, Linus Torvalds wrote:
>>
>>> But I haven't even looked at what non-selinux setups do to
>>> performance. Last time I tried Ubuntu (they still use apparmor, no?),
>>> "make modules_install ; make install" didn't work for the kernel, and
>>> if the Ubuntu people don't want to support kernel engineers, I
>>> certainly am not going to bother with them. Who uses smack?
>>
>> Tizen, perhaps a few others.
>
> Btw, it really would be good if security people started realizing that
> performance matters. It's annoying to see the security lookups cause
> 50% performance degradations on pathname lookup (and no, I'm not
> exaggerating, that's literally what it was before we fixed it - and
> no, by "we" I don't mean security people).

I take a bit of exception to this.  I do care.  Stephen Smalley, the
only other person who does SELinux kernel work, cares.  I don't speak
for other LSMs, but at least both of us who have done anything with
SELinux in the last years care.  I did the RCU work for selinux and
you, sds, and I did a bunch of work to stop wasting so much stack
space which was crapping on performance.  And I'm here again   :)

> Right now (zooming into the kernel only - ignoring the fact that make
> really spends a fair amount of time in user space) I get
>
>   9.79%      make  [k] __d_lookup_rcu
>   5.48%      make  [k] link_path_walk
>   2.94%      make  [k] avc_has_perm_noaudit
>   2.47%      make  [k] selinux_inode_permission
>   2.25%      make  [k] path_lookupat
>   1.89%      make  [k] generic_fillattr
>   1.50%      make  [k] lookup_fast
>   1.27%      make  [k] copy_user_generic_string
>   1.17%      make  [k] generic_permission
>   1.15%      make  [k] dput
>   1.12%      make  [k] inode_has_perm.constprop.58
>   1.11%      make  [k] __inode_permission
>   1.08%      make  [k] kmem_cache_alloc
>   ...

I tried something else, doing caching of the last successful security
check inside the isec.  It isn't race free, so it's not ready for
prime time.  But right now my >1% looks like:

  7.97%          make  [k] __d_lookup_rcu
  5.79%          make  [k] link_path_walk
  3.67%          make  [k] selinux_inode_permission
  2.02%          make  [k] lookup_fast
  1.90%          make  [k] system_call
  1.76%          make  [k] path_lookupat
  1.68%          make  [k] inode_has_perm.isra.45.constprop.61
  1.53%          make  [k] copy_user_enhanced_fast_string
  1.39%          make  [k] generic_permission
  1.35%          make  [k] kmem_cache_free
  1.30%          make  [k] __audit_syscall_exit
  1.13%          make  [k] kmem_cache_alloc
  1.00%          make  [k] strncpy_from_user

How do I tell what is taking time inside selinux_inode_permission?
--
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/