lkml.org 
[lkml]   [2017]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 3/3] tpm: vtpm_proxy: Add ioctl to request locality prepended to command
    From
    Date
    On 05/10/2017 08:47 AM, Jarkko Sakkinen wrote:
    > On Tue, May 09, 2017 at 11:49:05AM -0400, Stefan Berger wrote:
    >> On 05/08/2017 07:43 PM, Jarkko Sakkinen wrote:
    >>> On Thu, May 04, 2017 at 04:03:18PM -0400, Stefan Berger wrote:
    >>>> On 05/04/2017 02:40 PM, Jarkko Sakkinen wrote:
    >>>>> On Thu, May 04, 2017 at 07:14:27AM -0400, Stefan Berger wrote:
    >>>>>> On 05/04/2017 05:17 AM, Jarkko Sakkinen wrote:
    >>>>>>> On Wed, May 03, 2017 at 07:40:48PM -0400, Stefan Berger wrote:
    >>>>>>>> On 05/03/2017 06:37 PM, Jarkko Sakkinen wrote:
    >>>>>>>>> On Fri, Apr 28, 2017 at 09:02:18AM -0400, Stefan Berger wrote:
    >>>>>>>>>> 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 would suggest allocating CC's backwards starting from 0xFFFFFFFF for
    > these control messages and send them in regular TPM command layout. A
    > bit similar idea as we have in the RM.
    >
    > /Jarkko
    >

    \
     
     \ /
      Last update: 2017-05-10 21:21    [W:9.337 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site