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

[David Gibson]

On Tue, Jan 21, 2020 at 09:13:30AM -0500, Stefan Berger wrote:
> 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.

I think you may be talking at cross purposes here.

IIUC, the purpose of the *software* TPM specifically isn't really
about protecting guest integrity.  Or at least, not from a host-based
attack, since as you say it relies on KVM and QEMU.

For protecting (secure) guest integrity against the host we don't use
this software TPM emulation - instead we use the H_TPM_COMM hypercall
which talks to the *host* TPM.

> > > > +#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.
> 
> 
> _______________________________________________
> SLOF mailing list
> SLOF at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/slof
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20200122/f61d23a8/attachment.sig>