mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Daniel De Graaf
5c3705c900
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>
xen-bugtool =========== The xen-bugtool command line application will collate the Xen dmesg output, details of the hardware configuration of your machine, information about the build of Xen that you are using, plus, if you allow it, various logs. The information collated can either be posted to a Xen Bugzilla bug (this bug must already exist in the system, and you must be a registered user there), or it can be saved as a .tar.bz2 for sending or archiving. The collated logs may contain private information, and if you are at all worried about that, you should not use this tool, or you should explicitly exclude those logs from the archive. xen-bugtool is wholly interactive, so simply run it, and answer the questions.