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: <AANLkTinywnaMNSABWTBwTmC5ML9BRTGgU0+YCfZJSkCT@mail.gmail.com>
Date:	Tue, 26 Oct 2010 08:22:31 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	John Stoffel <john@...ffel.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	"J.H." <warthog9@...nel.org>, Eric Paris <eparis@...hat.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, zohar@...ibm.com,
	david@...morbit.com, jmorris@...ei.org, kyle@...artin.ca,
	hpa@...or.com, akpm@...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 Tue, Oct 26, 2010 at 7:01 AM, John Stoffel <john@...ffel.org> wrote:
>
> So the Kconfig should have 'default N' for IMA then?

ALL new features should have "default n" for them. And if you had
actually looked at it, you would see that it already has that ("n" is
the default if no default is listed) _and_ it says

  "If unsure, say N"

in the comments.

So why the hell are people complaining about a patch-series that
_clearly_ improves on the current situation?

And yes, Fedora should never have enabled it. If the distro doesn't
use a feature, it shouldn't be enabled, because it's inevitably just a
source of problems. In this case, I think we should be happy that it
was enabled just because it made people notice the problem, but at the
same time the fact that Fedora enabled it is _not_ justification for
then saying "well, if you enable it and don't use it, it must be
zero-overhead".

If you want zero overhead and you think nobody uses it (and that seems
to be the _only_ logic the people complaining about it keep drumming
on), then DON'T ENABLE IT, FOR CHRISSAKE!

This thread has been a total waste of everybody's time.

Did I miss any actual _constructive_ criticism of the patches? Is
there any reason I shouldn't actually apply them? If there is, I've
lost it in the roar of pointlessness.

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