linux-kernel - Re: [PATCH 0/2] ima: policy search speedup

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

Date:	Wed, 12 Dec 2012 09:25:25 -0500
From:	Eric Paris <eparis@...isplace.org>
To:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>
Subject: Re: [PATCH 0/2] ima: policy search speedup

On Wed, Dec 12, 2012 at 8:56 AM, Kasatkin, Dmitry
<dmitry.kasatkin@...el.com> wrote:

> I have done few tests.
> Ratio between lookups is different, but I do not really remember what
> exactly it was.
> Probably I did measurement with directory integrity protection...
>
> First test is done using upstream IMA.
>
> IMA-appraisal
> [   59.554072] counter1 - before (inode->i_flags & S_NOIMA): 74586
> [   59.554628] counter2 - after (inode->i_flags & S_NOIMA): 74558
> [   59.555024] counter3 - after (inode->i_sb->s_feature_flags & SF_NOIMA): 52895
>
> You can see 3 counters after 55 seconds uptime.
> Counters count entries to the policy search function.
> First counter counts every entry.
> Second counter counts if control passes after inode flag S_NOIMA.
> Third counts if control passes after SB flag SF_NOIMA.
>
> As you can see, inode flag does not make a difference - just 28
> entries differences.

That is quite shocking to me that on system start up we only ever
reference the same /proc file 28 times.  Wow.  I just don't know what
to say.  Obviously the per inode flag is dead.  Now there is probably
some CPU benefit to a per-sb flag, but I'm not sure it is worth the
code to do it if you can't really measure that as something that makes
a difference in userspace.

Maybe if you can show that after your integrity protection work is
done we can revisit.  But I'd think this patch is dead until you can
show the impact on real userspace.  Someone else might disagree, but
that's my thought.

Sorry.

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