All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, James Morris <jmorris@namei.org>,
	David Safford <safford@watson.ibm.com>,
	Serge Hallyn <serue@linux.vnet.ibm.com>,
	Mimi Zohar <zohar@us.ibm.com>
Subject: Re: [PATCH 2/3] integrity: Linux Integrity Module(LIM)
Date: Fri, 31 Oct 2008 09:51:42 -0700	[thread overview]
Message-ID: <1225471902.12673.415.camel@nimitz> (raw)
In-Reply-To: <20081014132823.GA18474@infradead.org>

On Tue, 2008-10-14 at 09:28 -0400, Christoph Hellwig wrote:
> > --- 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.

Why don't we just have a 'void *i_lots_of_bloat field', and let the
security folks stick whatever they want in it?  They can trade their
i_security space for a new one.  I know we want to conceptually separate
security from integrity, so let's separate it:

struct i_bloat_inodes {
#ifdef CONFIG_SECURITY
	void                    *i_security;
#endif
#ifdef CONFIG_INTEGRITY
	void                    *i_integrity;
#endif
};

By the way, if there's no TPM hardware, why would I want i_integrity
anyway?

-- Dave


  parent reply	other threads:[~2008-10-31 16:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-13 17:17 [PATCH 0/3] integrity Mimi Zohar
2008-10-13 17:17 ` [PATCH 1/3] integrity: TPM internel kernel interface Mimi Zohar
2008-10-14 22:23   ` Serge E. Hallyn
2008-10-22 12:47     ` Rajiv Andrade
2008-10-22 14:49       ` Serge E. Hallyn
2008-10-24 20:16         ` Rajiv Andrade
2008-10-24 20:31           ` Serge E. Hallyn
2008-10-13 17:17 ` [PATCH 2/3] integrity: Linux Integrity Module(LIM) Mimi Zohar
2008-10-14 13:28   ` Christoph Hellwig
2008-10-14 15:27     ` david safford
2008-10-14 15:53       ` Serge E. Hallyn
2008-10-14 17:06         ` david safford
2008-10-20 15:12       ` Serge E. Hallyn
2008-10-24 14:47     ` Mimi Zohar
2008-10-31 16:22     ` Serge E. Hallyn
2008-10-31 16:51     ` Dave Hansen [this message]
2008-10-31 19:48       ` Mimi Zohar
2008-10-14 23:27   ` Serge E. Hallyn
2008-10-31 16:40   ` Dave Hansen
2008-10-31 19:35     ` Mimi Zohar
2008-10-31 21:02       ` Dave Hansen
2008-11-02 22:57     ` Serge E. Hallyn
2008-10-13 17:17 ` [PATCH 3/3] integrity: IMA as an integrity service provider Mimi Zohar
2008-10-15  3:32   ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1225471902.12673.415.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=hch@infradead.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=safford@watson.ibm.com \
    --cc=serue@linux.vnet.ibm.com \
    --cc=zohar@linux.vnet.ibm.com \
    --cc=zohar@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.