vtpm_handle_cmd doesn't ensure there is enough space before unpacking
the req buffer. Add a minimum size check. Called functions will have
to do their own checking if they need more data from the request.
The error case is tricky since abort_egress wants to rely with a
corresponding tag. Just hardcode TPM_TAG_RQU_COMMAND since the vtpm is
sending in malformed commands in the first place.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
GetRandom passthrough currently fails when using vtpmmgr with a hardware
TPM 2.0.
vtpmmgr (8): INFO[VTPM]: Passthrough: TPM_GetRandom
vtpm (12): vtpm_cmd.c:120: Error: TPM_GetRandom() failed with error code (30)
When running on TPM 2.0 hardware, vtpmmgr needs to convert the TPM 1.2
TPM_ORD_GetRandom into a TPM2 TPM_CC_GetRandom command. Besides the
differing ordinal, the TPM 1.2 uses 32bit sizes for the request and
response (vs. 16bit for TPM2).
Place the random output directly into the tpmcmd->resp and build the
packet around it. This avoids bouncing through an extra buffer, but the
header has to be written after grabbing the random bytes so we have the
number of bytes to include in the size.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed by: Daniel P. Smith <dpsmith@apertussolutions.com>
Enables deep quote execution for vtpmmgr which can not be started
using locality 2. Flags are used to request additional data to be
present when executing quote. They are interpreted as a bitmask of:
* VTPM_QUOTE_FLAGS_HASH_UUID
* VTPM_QUOTE_FLAGS_VTPM_MEASUREMENTS
* VTPM_QUOTE_FLAGS_GROUP_INFO
* VTPM_QUOTE_FLAGS_GROUP_PUBKEY
The externData param for TPM_Quote is calculated as:
externData = SHA1 (
extraInfoFlags
requestData
[SHA1 (
[SHA1 (UUIDs if requested)]
[SHA1 (vTPM measurements if requested)]
[SHA1 (vTPM group update policy if requested)]
[SHA1 (vTPM group public key if requested)]
) if flags !=0 ]
)
The response param pcrValues is an array containing requested hashes used
for externData calculation : UUIDs, vTPM measurements, vTPM group update
policy, group public key. At the end of these hashes the PCR values are
appended.
Signed-off-by: Emil Condrea <emilcondrea@gmail.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This breaks the include cycle hypervisor.h -> hypercall-x86_32.h -> mm.h
-> lib.h -> gntmap.h -> os.h -> hypervisor.h.
Signed-off-by: Thomas Leonard <talex5@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Rather than using the internal MPI format for the Diffie-Hellman group,
whose representation depends on the size of the t_uint type, store the
value as a big-endian integer and use mpi_read_binary to convert it in
an architecture-independent manner. This patch also removes the
unnecessary range check on the exponent which ended up being different
between 32- and 64-bit code.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The internal MPI word size matches the word size of the platform rather
than using uint32_t/uint64_t, so constant MPI objects need to be
initialized with that in mind.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
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>
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>