Lines Matching refs:to
5 (VMs) and the host. As a result, the host is only allowed to access memory that
7 therefore able to manipulate secrets without being at risk of an attacker
13 Furthermore, even though the isolation mentioned above allows pVMs to protect
16 access to those secrets, preventing the VMM from passing them to the pVM.
22 the pVM, allowing it to validate the environment and abort the boot sequence if
26 Given the threat model, pvmfw is not allowed to trust the devices or device
28 by the VMM. Instead, it performs all the necessary checks to ensure that the pVM
34 [Open Profile for DICE][open-dice]) that can be used to prove the identity of
35 the pVM to local and remote actors. If any operation or check fails, or in case
38 Otherwise, it hands over the pVM to the guest kernel by jumping to its first
39 instruction, similarly to a bootloader.
58 to know how to interpret or obtain the content of that region.
65 of the [`boot`][boot-img] partition, intended to be verified and loaded by ABL
69 [`boot.img` header][boot-img] may be used to obtain the size of the `pvmfw.bin`
74 Note that when it gets executed in the context of a pVM, `pvmfw` expects to have
77 responsibility of the hypervisor to either reject the image or copy it into
80 To support pKVM, ABL is expected to describe the region using a reserved memory
81 device tree node where both address and size have been properly aligned to the
102 Bootloader, "ABL") is expected to pass device-specific pvmfw configuration data
103 by appending it to the pvmfw binary and including it in the region passed to the
104 hypervisor. As a result, the hypervisor will give the same protection to this
105 data as it does to pvmfw and will transparently load it in guest memory, making
106 it available to pvmfw at runtime. This enables pvmfw to be kept device-agnostic,
108 also being able to support device-specific details.
112 expected for it to also have been loaded at a 4-KiB boundary. As a result, the
113 location of the configuration data is implicitly passed to pvmfw and known to it
124 | (Padding to 4KiB alignment) |
154 | (Padding to 8-byte alignment) |
158 | (Padding to 8-byte alignment) |
162 | (Padding to 8-byte alignment) |
166 | (Padding to 8-byte alignment) |
170 | (Padding to 8-byte alignment) |
184 referred to by its offset in the entry array and may be mandatory or optional
186 size. It is therefore not allowed to trim missing optional entries from the end
190 blos it refers to. In version 1.0, it describes two blobs:
192 - entry 0 must point to a valid DICE chain handover (see below)
193 - entry 1 may point to a [DTBO] to be applied to the pVM device tree. See
198 - entry 2 may point to a [DTBO] that describes VM DA DTBO for
205 may be included in the device tree passed to a protected VM. pvmfw validates
212 This provides a mechanism to allow configuration information to be securely
213 passed to the VM via the host. pvmfw does not interpret the content of VM
214 reference DT, nor does it apply it to the VM's device tree, it just ensures
221 implementation to each VM.
223 - Passing the [vendor hashtree digest][vendor_hashtree_digest] to run
246 and contains the _Compound Device Identifiers_ ("CDIs"), used to derive the
254 can be passed to [`DiceAndroidHandoverMainFlow`][DiceAndroidHandoverMainFlow] along with
264 1. Passing the resulting `AndroidDiceHandover` to `DiceAndroidHandoverMainFlow`
270 code relevant to the secure execution of pvmfw (_e.g._ `vendor_boot.img`)
271 - **Configuration Data**: any extra input relevant to pvmfw security
272 - **Authority Data**: must cover all the public keys used to sign and verify the
273 code contributing to the **Code** input
274 - **Mode Decision**: Set according to the [specification][dice-mode]. In
281 The resulting `AndroidDiceHandover` is then used by pvmfw in a similar way to
282 derive another [DICE layer][Layering], passed to the guest through a
297 pvmfw is intended to run in a virtualized environment according to the `crosvm`
298 [memory layout][crosvm-mem] for protected VMs and so it expects to have been
300 `0x7fe0_0000` as scratch memory. It makes use of the virtual PCI bus to obtain a
301 virtio interface to the host and prints its logs through the 16550 UART (address
304 At boot, pvmfw discovers the running hypervisor in order to select the
305 appropriate hypervisor calls to share/unshare memory, mark IPA regions as MMIO,
347 the registers it receives is configured by the VMM and is expected to follow the
355 Images to be verified, which have been loaded to guest memory by the VMM prior
356 to booting the VM, are described to pvmfw using the device tree (x0):
385 above. It uses the device tree to pass the following:
406 by the next stages to ensure that an attacker isn't trying to force new
407 secrets to be generated by one stage, in isolation;
409 - the `/chosen/avf,strict-boot` flag, always set and can be used by guests to
416 kernel region (see `/config/kernel-{address,size}` described above) to contain
442 Note that the `/tmp/<initrd.bin>` file is only created to temporarily hold the
443 hash descriptor to be added to the kernel footer and that the unsigned
444 `<initrd.bin>` should be passed to the VMM when booting a pVM.
447 the signer to specify if pvmfw must consider the guest to be debuggable
452 the signing described above is recommended to be done through an
460 For faster iteration, you can build pvmfw, adb-push it to the device, and use
461 it directly for a new pVM, without having to flash it to the physical
463 above must be replicated to produce a single file containing the pvmfw binary
467 file][bcc.dat]) can be appended to the `pvmfw.bin` image with `pvmfw-tool`.
477 The result can then be pushed to the device. Pointing the system property
478 `hypervisor.pvmfw.path` to it will cause AVF to use that image as pvmfw:
492 Note: `adb root` is required to set the system property.