Lines Matching refs:to
23 =item 2. Provide a single controlled path of access to the physical TPM
40 which allows data to be bound to specific PCRs. These PCRs are populated in the
42 dynamic launch environment such as TBOOT. In order to provide assurance of the
43 system's security, the PCRs used to seal the TPM manager's data must contain
44 measurements for domains used to bootstrap the TPM Manager and vTPMs.
47 any component of the system is upgraded. Since it is not possible to construct a
49 configurations is delegated to a third party, referred to here as the system
51 which is used to sign lists of valid configurations. A single TPM manager can
54 tenants may not all choose to trust the same SAA.
56 Each vTPM is bound to a vTPM group at the time of its creation. Each vTPM group
58 used with a conforming Privacy CA, this allows each group on the system to form
65 provisioned with an SAA and a boot configuration in order to survive a reboot.
67 When a vTPM is connected to the TPM Manager using a UUID that is not recognized,
69 be restricted to specific UUIDs (such as the all-zero UUID) to enforce the use
70 of the TPM manager as the generator of the UUID. The first vTPM to be connected
72 to dom0 or a control domain in order to send provisioning commands.
75 privacy CA data used to certify the AIK (see the TPM spec for details). Once the
77 initial group controls the ability to boot the system as a whole, and cannot be
82 Command line arguments are passed to the domain via the 'extra' parameter in the
127 domain must have access to TPM IO memory. (default)
131 Use the Xen tpmfront interface to talk to another
132 domain which provides access to the TPM.
138 The following options only apply to the tpm_tis driver:
150 "probe" can be set to probe for the irq. A value of 0 disables
155 Attempt to use locality <LOC> of the hardware TPM.
156 For full functionality of the TPM Manager, this should be set to "2".
162 While the TPM Manager has the ability to check the hash of the vTPM requesting a
163 key, there is currently no trusted method to inform the TPM Manager of the hash
165 Xenstore to identify a vTPM in a trusted manner. The XSM policy may be used to
167 constrained (for example, only permitted to a domain builder service): the only
168 grants mapped by the TPM Manager should belong to vTPM domains, so restricting
169 the ability to map other domain's granted pages will prevent other domains from
174 A domain with direct access to the hardware TPM will be able to decrypt the TPM
177 configurations should be chosen to include PCRs that measure the hypervisor,
179 policy. If the TPM Manager is configured to use locality 2 as recommended, it
180 is safe to permit the hardware domain to access locality 0 (the default in
182 unexpected busy errors from the TPM driver. The ability to access locality 2 of
189 domain due to changes in the on-disk format and the method used to seal data.
190 If a vTPM domain supports migration, this feature should be used to migrate the
193 If adding migration support to the vTPM is not desired, a simpler migration
203 =item 3. Attach the vTPM migration domain's vtpm/0 device to the old vtpmmgr
209 =item 6. Attach the vTPM migration domain's vtpm/1 device to the new vtpmmgr
215 This requires the migration domain to be added to the list of valid vTPM kernel
223 The vTPM Manager requires a disk image to store its encrypted data. The image
225 is not large; the Xen 4.5 vtpmmgr is limited to using the first 2MB of the image
234 for storage and permission to access the hardware memory pages for the TPM. The
244 extra option to launch vtpmmgr-stubdom domain on TPM 2.0, and ignore it on TPM
278 Now the secrets for the vTPMs are only being bound to the presence of thephysical
279 TPM 2.0. Since using PCRs to seal the data can be an important security feature
281 TPM2_Seal/TPM2_Unseal to provide as much security as it did for TPM 1.2 in later
326 The Linux based guest that wants to use a vTPM. There many be
332 provides vTPM access to a para-virtualized Linux based DomU.
337 connects to this backend driver to facilitate
339 driver is also used by vtpmmgr-stubdom to communicate with
345 one to one mapping between running vtpm-stubdom instances and
347 Registers (PCRs) are all initialized to zero.
352 vtpm-stubdom uses this driver to communicate with
353 vtpmmgr-stubdom. This driver could also be used separately to
354 implement a mini-os domain that wishes to use a vTPM of
362 access to the physical TPM on the system and secures the
368 driver. This driver used by vtpmmgr-stubdom to talk directly
369 to the hardware TPM 2.0. Communication is facilitated by mapping