linux-kernel - Re: [PATCH 06/11] IMA: use i_writecount rather than a private counter

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: <1288043557.2655.34.camel@localhost.localdomain>
Date:	Mon, 25 Oct 2010 17:52:37 -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 06/11] IMA: use i_writecount rather than a private
 counter

On Mon, 2010-10-25 at 15:27 -0400, John Stoffel wrote:

> The problems with kernel.org is a perfect exmaple of how an annocuous
> feature like this, can kill a system's performance.

You admit that you don't know what you are talking about and then state
that this kills systems performance.  Interesting conclusion.

I'm not going to try to refute you point by point but will instead paint
a broad picture.  I see 3 possible states:
1) Configured out - 0 overhead.  period.
2) Configured in but default disabled
3) Configured in and enabled by admin intervention

I have (I think) pretty clearly discussed the overhead and the changes
made in case #2.  We expand struct inode by 4 bytes, we increment and
decrement those 4 bytes on open/close() and we use a new inode->i_flags.

In you e-mail you seemed to be asking about case #3 where you explicitly
chose to load a measurement policy (either custom or using the imb_tcb=1
boot option).  There are additional overheads in that case if the inode
in question matches the measurement policy.  I don't see the need to go
into the details of that overhead since you have 0 intention of using
this feature no matter what and don't seem to be interested in helping
to change those overheads for users of the subsystem.  Please correct me
if I'm wrong.  I do readily admit there is overhead, and that overhead
will be higher if inodes which have been deemed integrity relevant by
the measurement policy you chose to load are changed in certain
patterns.

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