On Wed, May 10, 2017 at 09:20:14AM -0400, Stefan Berger wrote:

On 05/10/2017 08:47 AM, Jarkko Sakkinen wrote:

quoted

On Tue, May 09, 2017 at 11:49:05AM -0400, Stefan Berger wrote:

quoted

On 05/08/2017 07:43 PM, Jarkko Sakkinen wrote:

quoted

On Thu, May 04, 2017 at 04:03:18PM -0400, Stefan Berger wrote:

quoted

On 05/04/2017 02:40 PM, Jarkko Sakkinen wrote:

quoted

On Thu, May 04, 2017 at 07:14:27AM -0400, Stefan Berger wrote:

quoted

On 05/04/2017 05:17 AM, Jarkko Sakkinen wrote:

quoted

On Wed, May 03, 2017 at 07:40:48PM -0400, Stefan Berger wrote:

quoted

On 05/03/2017 06:37 PM, Jarkko Sakkinen wrote:

quoted

On Fri, Apr 28, 2017 at 09:02:18AM -0400, Stefan Berger wrote:

quoted

Add an ioctl to request that the locality be prepended to every TPM
command.

Don't really understand this change. Why locality is prenpended?

Commands can be executed under locality 0-3 and for some commands it is
important to know which locality a user may have chosen. How else should we
convey that locality to the TPM emulator ?

Why this is not in the commit message?

More scalable way to do this would be to have a set of vtpm proxy
commands. There could be a command for requesting and releasing
locality. That would be more clean.

I would think that if someone wanted to use locality it's the client using
/dev/tpm(rm)0 calling an ioctl or so and the vtpm proxy then merely passing
that locality to the backend (TPM emulator). I suppose the intention is to
support something like that following the addition of the new functions
request_locality and release_locality?

What if we later on want to pass something else than locality to the
backend? How that will work out?

'push' more data in front. 'pop' off by recipient. We could wrap the command
in some form.

      Stefan

I would find having a set of special commands cleaner. Prepending sounds
like a quick hack to me, not really something that should exist in the
mainline.

Along the lines of this here?

uint32_2 command
uint32_2 totlength
uint8_t locality
uint8_t buffer[]  <- the actual TPM command


With a command code like VTPM_PROXY_CMD_TPM_CMD = 1.

    Stefan

That would break binary compability.

That's why I am adding that additional flag that allows a client to choose
whether it wants the TPM command wrapped (or locality prepended) so that it
knows what to expect from the driver. I don't think that breaks
compatibility.

I think having TPM command codes for control messages would be a
better idea and it is trivial to filter them so that client cannot
use those commands.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html