linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: dhowells@redhat.com, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@linux-nfs.org,
	linux-crypto@vger.kernel.org,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	James Morris <jmorris@namei.org>,
	David Safford <safford@watson.ibm.com>,
	Rajiv Andrade <srajiv@linux.vnet.ibm.com>,
	Mimi Zohar <zohar@us.ibm.com>
Subject: Re: [PATCH v1.4 4/5] keys: add new trusted key-type
Date: Fri, 19 Nov 2010 16:23:21 +0000	[thread overview]
Message-ID: <10330.1290183801@redhat.com> (raw)
In-Reply-To: <1290120166-3132-5-git-send-email-zohar@linux.vnet.ibm.com>

Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:

> +keyctl print returns an ascii hex copy of the sealed key, which is in standard

I'd quote 'keyctl print' just so it's obvious where the command ends and the
descriptive text starts.

> +Usage:
> +  keyctl add encrypted name "new key-type:master-key-name keylen" ring
> +  keyctl add encrypted name "load key-type:master-key-name keylen hex_blob" ring
> +  keyctl update keyid "update key-type:master-key-name"
> +
> +where 'key-type' is either 'trusted' or 'user'.

I recommend adding some example commands with all the arguments substituted.
Nothing helps get to grip with an API like knowing what a command is supposed
to look like when it's actually used.

> +static int trusted_tpm_send(u32 chip_num, unsigned char *cmd, int buflen)

There are still a lot of places in here where you should probably be using
const and size_t.

> +static int my_get_random(unsigned char *buf, int len)
> +{
> +	struct tpm_buf *tb;
> +	int ret;
> +
> +	tb = kzalloc(sizeof *tb, GFP_KERNEL);
> +	if (!tb)
> +		return -ENOMEM;
> +	ret = tpm_get_random(tb, buf, len);

Using kzalloc() rather than kmalloc() is a waste of time, I'd've thought.
It's a temporary buffer.  Does it really need to be precleared?

> +	ret = tpm_pcr_extend(TPM_ANY_NUM, pcrnum, hash);
> +	return ret;

Merge.

> +static int trusted_update(struct key *key, const void *data, size_t datalen)
> +{
> ...
> +	*(datablob + datalen) = '\0';

That's what [] is for.

> +	if (new_o)
> +		kfree(new_o);

kfree() can handle a NULL pointer.

> +	if (new_o->pcrlock)
> +		ret = pcrlock(new_o->pcrlock);
> +	rcu_assign_pointer(key->payload.data, new_p);
> +	call_rcu(&p->rcu, trusted_rcu_free);

Should there be a check for pcrlock() failure?

> +/* not already defined in tpm.h - specific to this use */
> +#define TPM_TAG_RQU_COMMAND		193
> +#define TPM_TAG_RQU_AUTH1_COMMAND	194
> ...

Values defined for TPM hardware access really ought to be in a separate file
in include/linux/.  They aren't strictly specific to the trusted key
implementation here; that may be the only user currently in the kernel, but
that doesn't mean there can't be another user.

David

  reply	other threads:[~2010-11-19 16:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-18 22:42 [PATCH v1.4 0/5] keys: trusted and encrypted keys Mimi Zohar
2010-11-18 22:42 ` [PATCH v1.4 1/5] lib: hex2bin converts ascii hexadecimal string to binary Mimi Zohar
2010-11-19 15:43   ` David Howells
2010-11-18 22:42 ` [PATCH v1.4 2/5] tpm: add module_put wrapper Mimi Zohar
2010-11-19 15:43   ` David Howells
2010-11-18 22:42 ` [PATCH v1.4 3/5] key: add tpm_send command Mimi Zohar
2010-11-19 15:45   ` David Howells
2010-11-19 16:04     ` David Safford
2010-11-19 16:45       ` David Howells
2010-11-18 22:42 ` [PATCH v1.4 4/5] keys: add new trusted key-type Mimi Zohar
2010-11-19 16:23   ` David Howells [this message]
2010-11-19 18:00     ` David Safford
2010-11-18 22:42 ` [PATCH v1.4 5/5] keys: add new key-type encrypted Mimi Zohar
2010-11-19 16:43   ` David Howells
2010-11-22 12:16     ` Mimi Zohar

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=10330.1290183801@redhat.com \
    --to=dhowells@redhat.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@linux-nfs.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=safford@watson.ibm.com \
    --cc=srajiv@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).