Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.
Signed-off-by: Quan Xu <quan.xu@intel.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
TPM2_Create is used to create an object that can be loaded into a
TPM using TPM2_Load(). If the command completes successfully, the
TPM will create the new object and return the object’s creation.
data (creationData), its public area (outPublic), and its encrypted
sensitive area (outPrivate). Preservation of the returned data is
the responsibility of the caller. The object will need to be loaded
(TPM2_Load()).
TPM2_Load is used to load objects into the TPM. This command is used
when both a TPM2B_PUBLIC and TPM2B_PRIVATE are to be loaded. If only
a TPM2B_PUBLIC is to be loaded, the TPM2_LoadExternal command is used.
Signed-off-by: Quan Xu <quan.xu@intel.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type of object and attributes combination that is
allowed by TPM2_Create() may be created by this command. The constraints
on templates and parameters are the same as TPM2_Create() except that a
Primary Storage Key and a Temporary Storage Key are not constrained to
use the algorithms of their parents.
Signed-off-by: Quan Xu <quan.xu@intel.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Because there is not currently a method for the vTPM Manager to obtain a
build hash of a vTPM, use the hash of the vTPM's XSM label as a
substitute. This allows the vTPM Manager to distinguish between vTPMs
intended to be paired with a hardware domain kernel (which cannot use
pv-grub) and vTPMs which are paired with a pv-grub domain and therefore
contain reliable measurements of the guest kernel in PCRs 4 and 5.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The TPM locality must be specified when using TPM_PCR_INFO_LONG for
TPM_Seal. Store the locality so it can be provided later.
Signed-off-by: Jason Andryuk <andryuk@aero.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This is a complete rewrite of the disk format and key hierarchy for the
TPM Manager. The new format supports multiple groups of vTPMs which
define the permitted configurations where a given vTPM's keys are
available, allowing upgrades of critical components while retaining the
secrecy of cryptographic keys.
New features of the TPM Manager are explained in the README and in the
definitions of the management commands in vtpm_manager.h.
New features for vTPMs:
1. The size of the state blob for a vTPM is expanded from 52 to 64
bytes in order to support future vTPMs using SHA-2/3 instead of SHA-1.
2. vTPMs can obtain a quote from the physical TPM with certain
resettable PCRs set to include information about the vTPM. This can be
used by a vTPM to provide evidence of its integrity, including the
secrecy of its EK, and for deep quotes.
Some additional changes made by this rewrite that may impact existing
users:
1. The value of WELLKNOWN_OWNER_AUTH was incorrect for the physical TPM;
the convention is to use all zero bits for well-known authentication
values, not all one bits.
2. Randomly generating the owner auth value for the physical TPM is no
longer supported, as it prevents later creation or certification of
AIKs (which the old manager did not support).
3. The vTPM Manager needs to be provisioned with a PCR composite and an
upgrade authority's public key before it will save data across boots.
The current implementation still has some limitations:
* 5 valid system PCR selections per group
* The vTPM Manager's disk can use at most 2MB of space
* The vTPM domain's build hash is always set to null/zero
Most of the code relating to upgrade and rollback protection is
currently stubbed out, but future versions can add:
* Support for using the TPM's monotonic counter to prevent rollback
of vTPM data by taking and restoring disk snapshots
* Masking the master disk encryption key using a value stored in the
TPM's NVRAM so that revocation of old data is possible without
relying on all previously authorized software stacks to respect the
monotonic counter's value
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Instead of only recording the UUID field, which may not be of interest
to all tpmback implementations, provide a user-settable opaque pointer
associated with the tpmback instance.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
The open/close callbacks in tpmback cannot be properly initalized in
order to catch the initial enumeration events because init_tpmback
clears the callbacks and then asynchronously starts the enumeration of
existing tpmback devices. Fix this by passing the callbacks to
init_tpmback so they can be installed before enumeration.
This also removes the unused callbacks for suspend and resume.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Quan Xu
Daniel De Graaf
Jason Andryuk
Matthew Fioravante