linux-kernel - Re: ima: use of radix tree cache indexing == massive waste of memory?

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: <20101017010917.GB8332@bombadil.infradead.org>
Date:	Sat, 16 Oct 2010 21:09:17 -0400
From:	Kyle McMartin <kyle@...artin.ca>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, kernel@...ts.fedoraproject.org,
	Mimi Zohar <zohar@...ibm.com>, warthog9@...nel.org,
	Dave Chinner <david@...morbit.com>,
	linux-kernel@...r.kernel.org, eparis@...hat.com
Subject: Re: ima: use of radix tree cache indexing == massive waste of memory?

On Sat, Oct 16, 2010 at 08:49:45PM -0400, Christoph Hellwig wrote:
> On Sat, Oct 16, 2010 at 02:10:29PM -0700, H. Peter Anvin wrote:
> > I'm confused ... what makes you think we are?  This might have been an unintentional misconfiguration...
> 
> I didn't mean to imply you enabled it intentionally.  In fact it looks
> like the inode tracking in IMA is always on once it's compiled in, which
> totally defeats the purpose of doing it's on iternal inode tracking
> instead of bloating the inode what they originally proposed.  IMA really
> needs a kernel parameter to only enabled this crap when people actually
> use it.
> 
> And whoever turned it on in Fedora needs some serious wahcking.
> 

Hey Eric, sorry to throw you under the bus, but...

1.316        (eparis   11-Aug-09): CONFIG_IMA=y

Perhaps we should stop merging crap into the kernel if it's not supposed
to be enabled. (Granted, IMA is better than 99% of the random junk
merged in a release, it actually has somewhat useful Kconfig help text,
unlike the thousands of crap drivers that get merged which provide no
hint to what obscure medieval ARM board found only on three silicon
revisions two of which were never released they were for.)

The Kconfig description sounds generally useful to me. If it's bloated
crap, how did it get merged?

Sigh.

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