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
next prev parent reply other threads:[~2010-11-24 16:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1290556535.2604.16.camel@localhost.localdomain>
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-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
2010-12-01 17:48 ` [PATCH v1.5 4/5] keys: add new trusted key-type David Howells
2010-12-01 21:18 ` David Safford
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 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).