All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Safford <safford@watson.ibm.com>
To: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@linux-nfs.org,
	linux-crypto@vger.kernel.org, David Howells <dhowells@redhat.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	James Morris <jmorris@namei.org>,
	Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Subject: Re: [PATCH v1.5 3/5] key: add tpm_send command
Date: Wed, 24 Nov 2010 11:31:23 -0500	[thread overview]
Message-ID: <1290616283.2785.36.camel@localhost.localdomain> (raw)
In-Reply-To: <20101124145925.GA2203@tiny>

On Wed, 2010-11-24 at 08:59 -0600, Serge Hallyn wrote:
> Quoting David Safford (safford@watson.ibm.com):
> > On Tue, 2010-11-23 at 20:32 -0600, Serge Hallyn wrote:
> > > Quoting Mimi Zohar (zohar@linux.vnet.ibm.com):
> > > > Add internal kernel tpm_send() command used to seal/unseal keys.
> > ... 
> > > > +int tpm_send(u32 chip_num, void *cmd, size_t buflen)
> > > 
> > > Hate to nit-pick, but any particular reason you're not following the
> > > rest of the file and using 'struct tpm_cmd_t *cmd' here?
> > > 
> > > Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> > 
> > We put some thought into this one. TPM command packets are
> > binary blobs with lots of optional and variable length fields,
> > and there are at least three common approaches to creating them:
> > structures (as used in tpm.c), load/store (as used in trousers
> > and trusted-keys), and an sprintf like format string (as used
> > in the original libtpm.) Each has its advantages and disadvantages.
> > Structures are nice for the simple TPM commands, but they become
> > unwieldy for the complex commands like seal and unseal. Load/store
> > is much more readable for the complex seal and unseal commands.
> > Format strings are nice for creating the most complex commands
> > in the fewest lines of code, but are way overkill for simple ones.
> > 
> > With the void *cmd, we are allowing the other modules to pick
> > whichever method most suits their needs.
> 
> Jinkeys, that's complicated :)
> 
> But doesn't that mean that the transmit_cmd() parameters are lying?
> Should the second argument for transmit_cmd() be a union?
> 
> (If only to help out the lamentable reader)
> 
> thanks,
> -serge
ah.
transmit_cmd() takes a struct tpm_cmd_t * and immediately casts
it to u8 * for tpm_transmit(). So sending in a u8 * isn't
so much lying as recognizing that tpm_cmd_t * and u8 * are
equivalent :-) 
I suppose a union would be more correct, although I'm not
sure it would be easier for the lamentable reader...

dave



  reply	other threads:[~2010-11-24 16:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-23 22:50 [PATCH v1.5 0/5] keys: trusted and encrypted keys Mimi Zohar
2010-11-23 22:50 ` [PATCH v1.5 2/5] tpm: add module_put wrapper Mimi Zohar
2010-11-24  2:19   ` Serge Hallyn
2010-11-23 22:50 ` [PATCH v1.5 4/5] keys: add new trusted key-type Mimi Zohar
2010-12-01 17:48   ` David Howells
2010-12-01 21:18     ` David Safford
2010-11-23 23:43 ` [PATCH v1.5 1/5] lib: hex2bin converts ascii hexadecimal string to binary Mimi Zohar
2010-11-23 23:54 ` [PATCH v1.5 3/5] key: add tpm_send command Mimi Zohar
2010-11-24  2:32   ` Serge Hallyn
2010-11-24 12:46     ` David Safford
2010-11-24 14:59       ` Serge Hallyn
2010-11-24 16:31         ` David Safford [this message]
2010-11-30 14:32     ` David Howells
2010-11-30 15:22       ` David Safford
2010-11-24 16:21 ` [PATCH v1.5 5/5] keys: add new key-type encrypted Mimi Zohar
2010-11-28 21:56 ` [PATCH v1.5 0/5] keys: trusted and encrypted keys James Morris
     [not found] ` <1290556535.2604.16.camel@localhost.localdomain>
2010-12-03 13:42   ` [PATCH v1.5 5/5] keys: add new key-type encrypted David Howells
2010-12-07 22:48     ` Mimi Zohar
2010-12-08 10:54       ` David Howells

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=1290616283.2785.36.camel@localhost.localdomain \
    --to=safford@watson.ibm.com \
    --cc=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=serge.hallyn@canonical.com \
    --cc=srajiv@linux.vnet.ibm.com \
    --cc=zohar@linux.vnet.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.