[SLOF] [PATCH v6 4/7] tpm: Add TPM CRQ driver implementation

[Stefan Berger]

On 1/20/20 10:40 PM, Alexey Kardashevskiy wrote:
>
> On 21/01/2020 02:45, Stefan Berger wrote:
>> On 1/20/20 3:09 AM, Alexey Kardashevskiy wrote:
>>> All this can be reduces to "QEMU has vTPM support since the v5.0.0
>>> release", or similar.
>>
>> I will do that then.
>>
>>
>>>> +
>>>> +To start a QEMU VM with an attached vTPM (swtpm), run the following
>>>> commands
>>>> +as 'root'.
>>> Why as 'root'? Will swtpm forward these requests to an actual tpm
>>> device? How is it expected to work on the real system?
>>
>> I will modify this to use sudo for qemu.
>>
>> The hardware TPM cannot be used for virtualization so we won't forward
>> anything to it.
>
> So KVM+QEMU have to be trusted? The scope of the feature is not
> extremely clear but I am learning as we speak so may be it is.


Yes, and the host's integrity measurement architecture would have to 
take measurements of them plus all their dependencies and also the SLOF 
file.


>
>
>>
>>> +#undef PAPR_VTPM_DEBUG
>>> +//#define PAPR_VTPM_DEBUG
>>> +#ifdef PAPR_VTPM_DEBUG
>>> +#define dprintf(_x ...) do { printf("VTPM CRQ: " _x); } while(0)
>>> +#else
>>> +#define dprintf(_x ...)
>>> +#endif
>>> +
>>> +#define MIN(a, b) ((a) > (b) ? (b) : (a))
>>> +
>>> +/* layout of the command request queue for vTPM */
>>>
>>> Is every single packed struct added by this patch defined as a big
>>> endian?
>> Every structure interacting with the hypervisor/QEMU is defined as big
>> endian and this is the only packed data structure in this patch, so yes,
>> it is big endian. The rest can be native.
>>
>> [TPM 2 commands are all in big endian.]
>
> It is not that clear what structures are for TPM2 commands and which are
> from the TCG specs with that little endian log and so on.


I added some comments now to the data structures and also renamed some 
of them to better reflect those specs.