linux-kernel - Re: [PATCH 1/3] IMA: move read/write counters into struct inode

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]

Date:	Wed, 20 Oct 2010 10:46:36 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	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
Subject: Re: [PATCH 1/3] IMA: move read/write counters into struct inode

On Wed, 2010-10-20 at 16:38 +0200, Ingo Molnar wrote:
> * Eric Paris <eparis@...hat.com> wrote:
> 
> > Executive summary of the day's work:
> > Yesterday morning: 944 bytes per inode in core
> > Yesterday night: 24 bytes per inode in core
> > Tonight: 4 bytes per inode in core.
> > 
> > That's a x236 time reduction in memory usage.  No I didn't even start looking at a 
> > freezer.  Which could bring that 4 down to 0, but would add a scalability penalty 
> > on all inodes when IMA was enabled.
> 
> Why not use inode->i_security intelligently? That already exists so that way it's 0 
> bytes.
> 
> Thanks,

It still wouldn't be 0 bytes since there would be a 1-1 mapping from
inode to i_security structs.  It would just be hiding the memory
somewhere else so it's harder to spot.  And that's exactly how we got
into this situation, instead of just doing thing in the inode we hid it
away in a radix tree node and ima_iint_cache.  In any case it would
require a secondary structure

struct generic_lsm_inode_structure
{
	IMA Fields
	void *lsm_inode_structure;
}

Which means yet another pointer to the real per LSM inode struct.  So it
would actually likely cost memory....

The real reason I don't pursue this route is because of the litany of
different ways this pointer is used in different LSMs (or not used at
all.)  And we all know that LSM authors aren't known for seeing the
world the same way as each other.  As a maintainer of one of those LSMs
even I'm scared to try pushing that forward....

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