linux-kernel - Re: [PATCH 3/6] integrity: IMA as an integrity service provider

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, 03 Dec 2008 10:31:14 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	James Morris <jmorris@...ei.org>,
	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	David Safford <safford@...son.ibm.com>,
	Serge Hallyn <serue@...ux.vnet.ibm.com>,
	Mimi Zohar <zohar@...ibm.com>
Subject: Re: [PATCH 3/6] integrity: IMA as an integrity service provider

On Wed, 2008-12-03 at 13:17 -0500, Mimi Zohar wrote:
> On Tue, 2008-12-02 at 15:35 -0800, Dave Hansen wrote: 
> > > +config IMA_MEASURE_PCR_IDX
> > > +	int "PCR for Aggregate (8 <= Index <= 14)"
> > > +	depends on IMA
> > > +	range 8 14
> > > +	default 10
> > > +	help
> > > +	  IMA_MEASURE_PCR_IDX determines the TPM PCR register index
> > > +	  that IMA uses to maintain the integrity aggregate of the
> > > +	  measurement list.  If unsure, use the default 10.
> > 
> > Why would you want to change this?  Can it be done at runtime instead of
> > compile time?  I don't know what a PCR is.
> 
> The only reason to change it would be if in the future, TCG decides on a
> standard PCR for IMA, other than 10, or if they pick 10 for something
> else. We really don't need a runtime variable for this, but kconfig
> makes it easy to change once if necessary in the future.

OK.  Could you take out the prompt for now?  You can use Kconfig for
values that don't give user prompts.  I just don't think it is something
that people need to see.

in mm/Kconfig, for instance:

config NR_QUICK
        int
        depends on QUICKLIST
        default "2" if SUPERH || AVR32
        default "1"

> > > +int ima_iint_insert(struct inode *inode)
> > > +{
> > > +	struct ima_iint_cache *iint;
> > > +	int rc = 0;
> > > +
> > > +	iint = kzalloc(sizeof(*iint), GFP_KERNEL);
> > 
> > Does this basically get done for every inode, or only special ones?  I
> > just wonder if having a dedicated slab with a constructor to do
> > redundant things like mutex_init() would be helpful.
> 
> every inode, except those allocated before init_latecall.

I'd be willing to bet that you'll see a measurable performance
improvement if you decide to use a slab here.  All of the inodes for the
different fs's use slabs and these are at least as common as any single
fs's inode.  Also, using the con/destructors will save some work at each
object creation.

> > > +static void ima_add_boot_aggregate(void)
> > > +{
> > > +	struct ima_inode_measure_entry measure_entry;
> > > +	struct ima_store_template_data template = {
> > > +		.name = "ima",
> > > +		.len = sizeof(measure_entry),
> > > +		.data = (char *)&measure_entry,
> > > +	};
> > > +	int namelen, result;
> > > +
> > > +	memset(&measure_entry, 0, sizeof measure_entry);
> > > +	namelen = strlen(boot_aggregate_name);
> > > +	if (namelen > IMA_EVENT_NAME_LEN_MAX)
> > > +		namelen = IMA_EVENT_NAME_LEN_MAX;
> > > +	memcpy(measure_entry.file_name, boot_aggregate_name, namelen);
> > > +
> > > +	if (ima_used_chip) {
> > > +		int i;
> > > +		u8 pcr_i[IMA_DIGEST_SIZE];
> > > +		struct hash_desc desc;
> > > +		struct crypto_hash *tfm;
> > > +		struct scatterlist sg;
> > 
> > All of this stack stuff with very important, large sounding names makes
> > me nervous.  Can you reassure me?
> 
> The crypto code here will be moved to ima_crypto.c and will be
> refactored, cleaning up the code. Both measure_entry and template could
> be allocated/freed each time, but does that make sense?

That's reassuring, thanks. :)

-- Dave

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