Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)

[Serge E. Hallyn]

Quoting david safford (safford@xxxxxxxxxxxxxx):
> On Tue, 2008-10-14 at 09:28 -0400, Christoph Hellwig wrote:
> > >  }
> > >  
> > >  /*
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index 32477e8..349d548 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -683,6 +683,9 @@ struct inode {
> > >  #ifdef CONFIG_SECURITY
> > >  	void			*i_security;
> > >  #endif
> > > +#ifdef CONFIG_INTEGRITY
> > > +	void			*i_integrity;
> > > +#endif
> > 
> > Sorry, but as said before bloating the inode for this is not an option.
> > Please use something like the MRU approach I suggested in the last
> > review round.
> 
> Sorry, in that thread I thought we were ok, as Serge made the points
> that the bloat would only affect Integrity compiled kernels, that
> no one would press for making Integrity default (not only because of the
> bloat, but even more so because of the performance impact of hashing
> all the files), and that having LIM do MRU would be a big hit, as
> LIM allocates i_integrity for all inodes, and references it on all
> inode_permission, bprm and mmap calls.  

Yes I have to say that in this case, where every inode will have the
field in use, using MRU doesn't seem to make sense.  It's the ideal
case for putting it straight in the inode.

But I hear Mimi is trying it out, so she can report about any
resulting implementation and performance problems.

> If we have to, we have to, but we certainly would prefer not to.
> 
> thanks
> dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/