From: "J.H." <warthog9@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, Mimi Zohar <zohar@us.ibm.com>,
devel@lists.fedoraprojet.org
Subject: Re: ima: use of radix tree cache indexing == massive waste of memory?
Date: Sat, 16 Oct 2010 17:54:11 -0700 [thread overview]
Message-ID: <4CBA4933.1080108@kernel.org> (raw)
In-Reply-To: <20101017003526.GA29677@dastard>
On 10/16/2010 05:35 PM, Dave Chinner wrote:
> On Sat, Oct 16, 2010 at 02:10:29PM -0700, H. Peter Anvin wrote:
>> "Christoph Hellwig" <hch@infradead.org> 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.
>>
>> I'm confused ... what makes you think we are? This might have
>> been an unintentional misconfiguration...
>
> It's enabled in the kernel that is running:
>
> $ grep CONFIG_IMA /boot/config-2.6.34.7-56.fc11.x86_64
> CONFIG_IMA=y
> CONFIG_IMA_MEASURE_PCR_IDX=10
> CONFIG_IMA_AUDIT=y
> CONFIG_IMA_LSM_RULES=y
> $
>
> and it's using lots of memory, so if you're not actually using it I
> think it should be disabled.
>
> If this is a stock fedora config, then they've got some work to
> do....
Considering the only change to the RPM I made for 2.6.34 (the kernel
currently running on master) was a one line change to get XFS to not
kill the box, it's standard.
Taking a quick glance at my laptop (F12) I'll note the following:
config-2.6.32.16-150.fc12.x86_64:CONFIG_IMA=y
config-2.6.32.16-150.fc12.x86_64:CONFIG_IMA_MEASURE_PCR_IDX=10
config-2.6.32.16-150.fc12.x86_64:CONFIG_IMA_AUDIT=y
config-2.6.32.16-150.fc12.x86_64:CONFIG_IMA_LSM_RULES=y
config-2.6.32.21-166.fc12.x86_64:CONFIG_IMA=y
config-2.6.32.21-166.fc12.x86_64:CONFIG_IMA_MEASURE_PCR_IDX=10
config-2.6.32.21-166.fc12.x86_64:CONFIG_IMA_AUDIT=y
config-2.6.32.21-166.fc12.x86_64:CONFIG_IMA_LSM_RULES=y
config-2.6.32.21-168.fc12.x86_64:CONFIG_IMA=y
config-2.6.32.21-168.fc12.x86_64:CONFIG_IMA_MEASURE_PCR_IDX=10
config-2.6.32.21-168.fc12.x86_64:CONFIG_IMA_AUDIT=y
config-2.6.32.21-168.fc12.x86_64:CONFIG_IMA_LSM_RULES=y
So I would happily punt this at Fedora as an issue upstream (Fedora) in
this case. This seems to be a boolean value inside the kernel, it's
either enabled, or it's not.
There does seem to be a boot option to disable it, but it seems to be on
by default if it's compiled in, and it's not like it's obvious that this
is there and chewing up resources, is there a way to find out how much
memory this is chewing up?
I can understand the distributions wanting to turn this on, there is
likely user requests to be able to use this. It's just annoying that
it's completely non-obvious that this change went in, it's on by default
and it's stealing memory, particularly when it's not being used for
anything.
Speaking to TPM, it's not quite an entire waste of resources - you can
use it as a random number generator source from hardware, so that's
useful - can't say much beyond that.
- John 'Warthog9' Hawley
next prev parent reply other threads:[~2010-10-17 0:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-16 6:52 ima: use of radix tree cache indexing == massive waste of memory? Dave Chinner
2010-10-16 19:20 ` Christoph Hellwig
2010-10-16 21:10 ` H. Peter Anvin
2010-10-17 0:35 ` Dave Chinner
2010-10-17 0:54 ` J.H. [this message]
2010-10-17 2:11 ` Dave Chinner
2010-10-18 18:12 ` J.H.
2010-10-17 0:49 ` Christoph Hellwig
2010-10-17 1:09 ` Kyle McMartin
2010-10-17 1:13 ` Christoph Hellwig
2010-10-17 5:49 ` Ingo Molnar
2010-10-17 5:40 ` Ingo Molnar
2010-10-17 18:46 ` Christoph Hellwig
2010-10-18 0:49 ` James Morris
2010-10-18 6:25 ` Kyle McMartin
2010-10-18 6:36 ` Andrew Morton
2010-10-18 9:29 ` Dave Chinner
2010-10-18 13:31 ` Mimi Zohar
2010-10-18 20:50 ` Ware, Ryan R
2010-10-26 7:31 ` Pavel Machek
2010-10-18 16:03 ` Mimi Zohar
2010-10-18 19:24 ` John Stoffel
2010-10-18 16:46 ` Ryan Ware
2010-10-18 16:48 ` Eric Paris
2010-10-18 17:10 ` Kyle McMartin
2010-10-18 17:34 ` Kyle McMartin
2010-10-18 17:56 ` Linus Torvalds
2010-10-18 18:13 ` Eric Paris
2010-10-18 18:19 ` Ingo Molnar
2010-10-18 18:43 ` Eric Paris
2010-10-19 0:58 ` Eric Paris
2010-10-18 18:06 ` H. Peter Anvin
2010-10-18 18:11 ` Ingo Molnar
2010-10-18 18:13 ` H. Peter Anvin
2010-10-25 13:18 ` Pavel Machek
2010-10-17 5:57 ` Mimi Zohar
2010-10-17 11:02 ` Peter Zijlstra
2010-10-17 13:12 ` Eric Paris
2010-10-17 13:59 ` Peter Zijlstra
2010-10-17 14:04 ` Peter Zijlstra
2010-10-17 14:16 ` Eric Paris
2010-10-18 11:57 ` Peter Zijlstra
2010-10-18 14:59 ` Ted Ts'o
2010-10-18 15:02 ` Peter Zijlstra
2010-10-18 15:02 ` Eric Paris
2010-10-17 18:52 ` Christoph Hellwig
2010-10-18 16:44 ` Ryan Ware
2010-10-18 0:07 ` Dave Chinner
2010-10-17 14:09 ` Mimi Zohar
2010-10-17 18:49 ` Christoph Hellwig
2010-10-17 19:39 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2010-10-18 15:09 Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CBA4933.1080108@kernel.org \
--to=warthog9@kernel.org \
--cc=david@fromorbit.com \
--cc=devel@lists.fedoraprojet.org \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zohar@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox