Message-ID: <AANLkTinNbF9=5Ojn8kKEvSkGbpqQw+DGKyRWhAD1AYZK@mail.gmail.com>
Date:	Sun, 17 Oct 2010 09:12:47 -0400
From:	Eric Paris <eparis@...isplace.org>
To:	Peter Zijlstra <peterz@...radead.org>, eparis@...hat.com
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	Dave Chinner <david@...morbit.com>,
	linux-kernel@...r.kernel.org, Mimi Zohar <zohar@...ibm.com>,
	warthog9@...nel.org, hpa@...or.com, devel@...ts.fedoraprojet.org
Subject: Re: ima: use of radix tree cache indexing == massive waste of memory?

On Sun, Oct 17, 2010 at 7:02 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Sun, 2010-10-17 at 01:57 -0400, Mimi Zohar wrote:
>> On Sat, 2010-10-16 at 15:20 -0400, Christoph Hellwig wrote:
>> > Besides the algorithmic problems with ima, why is kernel.org using
>> > IMA to start with?  Except for IBM looking for a reason to jusity why
>> > TPM isn't a completely waster of ressources it's pointless.  And it was
>> > only merged under the premise that it would not affect innocent normal
>> > users.
>> >
>>
>> Can we keep this at the design level please? When IMA is enabled, it
>> needs to store information on a per inode basis, yet has to wait to
>> late_initcall() for the TPM, at which point some inodes would have
>> already been created.
>
> Being build (CONFIG_IMA=y) is not the same as default enabled. Is there
> a way to build this stuff and not have it enabled?

IMA isn't really 'enabled' by default (then again people might not
call it 'disabled' either).  When 'enabled' IMA takes cryptographic
hashes of the contents of files, stores those in a list, and backs
that list storage with the TPM.  If we expect IMA to ever transfer
from disabled to enabled we actually need a small amount of
information about inodes from the time it was disabled.  We need to
know how many things have the given inode open for read and how many
for write.  The reason it needs this information is that it needs to
be able to realize the the value of a cryptographic hash of the
contents of a file is useless if some other process is able to change
those contents immediately after the measurement.  I haven't looked
closely, but we could probably get away with only knowing the number
of writers.  Today, we collect readers, writers, and total number with
it open (should be equal to readers+writers) because that debugging
has found and fixed where a couple of filesystems are doing dumb
things.  Maybe we could get rid of readers/total but then we have no
idea when 'some random fs' does something which makes the writers
count incorrect.

Today, by default, when 'not enabled' we create a full data structure
which includes the reader/writer count, space for cryptographic
information, and a couple of other little things and store them in a
radix tree just for the reader/writer count.  I believe that if we
stored the writer count in the inode we could probably delay the
creation of the full structure until it was needed.  But at the time
of merging/review putting anything in the inode was rejected and we
were told to use a radix tree.

We could split this into 2 structures, thus greatly shrinking the size
of the structure needed for the default/disabled case, but it doesn't
help the fact that the suggested structure for storage (the radix
tree) is apparently quite inefficient.  I'd love to hear other
suggestions for a better structure....

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

Powered by blists - more mailing lists