linux-kernel - Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache

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: <1288042483.2655.16.camel@localhost.localdomain>
Date:	Mon, 25 Oct 2010 17:34:43 -0400
From:	Eric Paris <eparis@...hat.com>
To:	John Stoffel <john@...ffel.org>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, hch@...radead.org, zohar@...ibm.com,
	warthog9@...nel.org, david@...morbit.com, jmorris@...ei.org,
	kyle@...artin.ca, hpa@...or.com, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, mingo@...e.hu,
	viro@...iv.linux.org.uk
Subject: Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode
 information cache

On Mon, 2010-10-25 at 15:21 -0400, John Stoffel wrote:
> >>>>> "Eric" == Eric Paris <eparis@...hat.com> writes:

> Which seems to fly in the face of your claim that it needs to be able
> to re-enable itself by tracking open inodes even when disabled.

You're confusing multiple completely unrelated things.  Your confusing
loading an IMA measurement policy vs IMA indicating that it's
measurements may be unreliable.

> As the number of inodes goes up (say during a backup which reads
> them...) won't the size of this cache go up as well, even when IMA is
> disabled?  Why is this overhead even needed?

At the end of this patch the number of integrity structures still has a
1-1 mapping with the number of inodes.  If you look at the entire series
you will see that is not the case.

This patch by itself will cut the memory usage per inode by almost 600
bytes.

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