summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/VirtioFsDxe: implement the wrapper function for FUSE_FORGETLaszlo Ersek2020-12-214-0/+100
| | | | | | | | | | | | | | | | Add the VirtioFsFuseForget() function, for sending the FUSE_FORGET command to the Virtio Filesystem device. This is an unusual command in that it doesn't generate any response from the FUSE server. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-13-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()Laszlo Ersek2020-12-2115-1/+432
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the help of the VirtioFsFuseOpenDir() and VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now open and close the root directory. So let's implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(). OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the root directory of the filesystem. Thus, we have to start tracking references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the virtio-fs device while files are open. There are two methods that release an EFI_FILE_PROTOCOL object: the Close() and the Delete() member functions. In particular, they are not allowed to fail with regard to resource management -- they must release resources unconditionally. Thus, for rolling back the resource accounting that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to implement the first versions of EFI_FILE_PROTOCOL.Close() and EFI_FILE_PROTOCOL.Delete() in this patch as well. With this patch applied, the UEFI shell can enter the root directory of the Virtio Filesystem (such as with the "FS3:" shell command), and the "DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according to the virtiofsd log. The "DIR" command reports the root directory as if it were empty; probably because at this time, we only allow the shell to open and to close the root directory, but not to read it. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-12-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: add shared wrapper for FUSE_RELEASE / FUSE_RELEASEDIRLaszlo Ersek2020-12-214-0/+142
| | | | | | | | | | | | | | The FUSE_RELEASE and FUSE_RELEASEDIR commands only differ in the opcode. Add a common function called VirtioFsFuseReleaseFileOrDir() for sending either command. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-11-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: implement the wrapper function for FUSE_OPENDIRLaszlo Ersek2020-12-214-0/+143
| | | | | | | | | | | | | Add the VirtioFsFuseOpenDir() function, for sending the FUSE_OPENDIR command to the Virtio Filesystem device. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-10-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: submit the FUSE_INIT request to the deviceLaszlo Ersek2020-12-216-8/+182
| | | | | | | | | | | | | | | | Submit the FUSE_INIT request to the Virtio Filesystem device, for starting the FUSE session. The FUSE_INIT request is logged by the virtio-fs daemon, with this patch applied, when (for example) using the "CONNECT" UEFI shell command. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-9-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: map "errno" values to EFI_STATUSLaszlo Ersek2020-12-212-0/+205
| | | | | | | | | | | | | | | | | | | The VirtioFsFuseCheckResponse() function dedicates the EFI_DEVICE_ERROR status code to the case when the Virtio Filesystem device explicitly returns an error via the "VIRTIO_FS_FUSE_RESPONSE.Error" field. Said field effectively carries a Linux "errno" value. Introduce a helper function for mapping "errno" values to (hopefully) reasonable EFI_STATUS codes. This way we'll be able to propagate "errno" values as EFI_STATUS return codes along the UEFI call stack -- in some detail anyway. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-8-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: introduce the basic FUSE request/response headersLaszlo Ersek2020-12-214-0/+287
| | | | | | | | | | | | | | | | | | | | | | Introduce the VIRTIO_FS_FUSE_REQUEST and VIRTIO_FS_FUSE_RESPONSE structures, which are the common headers for the various FUSE request/response structures. Introduce the VirtioFsFuseNewRequest() helper function for populating VIRTIO_FS_FUSE_REQUEST, from parameters and from a VIRTIO_FS-level request counter. Introduce the VirtioFsFuseCheckResponse() helper function for verifying most FUSE response types that begin with the VIRTIO_FS_FUSE_RESPONSE header. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-7-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: add a scatter-gather list data typeLaszlo Ersek2020-12-212-0/+461
| | | | | | | | | | | | | | | | | | | | | | | In preparation for the variously structured FUSE request/response exchanges that virtio-fs uses, introduce a scatter-gather list data type. This will let us express FUSE request-response pairs flexibly. Add a function for validating whether a (request buffer list, response buffer list) pair is well-formed, and supported by the Virtio Filesystem device's queue depth. Add another function for mapping and submitting a validated pair of scatter-gather lists to the Virtio Filesystem device. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-6-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: suppress useless VS2019 warning about signed/unsigned comparison in VirtioFsSgListsValidate()]
* OvmfPkg/VirtioFsDxe: implement virtio device (un)initializationLaszlo Ersek2020-12-215-2/+412
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the VirtioFsInit(), VirtioFsUninit(), and VirtioFsExitBoot() functions. In VirtioFsInit(): - Verify the host-side config of the virtio-fs device. - Save the filesystem label ("tag") for later, from the configuration area of the virtio-fs device. - Save the virtio queue size for later as well. - Set up the virtio ring for sending requests. In VirtioFsUninit(): - Reset the device. - Tear down the virtio ring. In VirtioFsExitBoot(): - Reset the device. With this patch, the UEFI connect / disconnect controller operations involve virtio setup / teardown; they are visible in the virtio-fs daemon's log file. The virtiofsd log also confirms the device reset in VirtioFsExitBoot(), when an OS is booted while the virtio-fs device is bound. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-5-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFsLaszlo Ersek2020-12-215-3/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Complete the Supported, Start, and Stop member functions of EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver model: - bind virtio-fs devices, - produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them. On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 -- see <https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>). Beyond that, no actual Virtio setup is performed for now. Those bits are going to be implemented later in this series. On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume() function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member function -- is a stub; it always returns EFI_NO_MEDIA, for now. The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used to test this patch. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-4-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: introduce VirtioFsDxeLaszlo Ersek2020-12-218-0/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the driver is to ease file exchange (file sharing) between the guest firmware and the virtualization host. The driver is supposed to interoperate with QEMU's "virtiofsd" (Virtio Filesystem Daemon). References: - https://virtio-fs.gitlab.io/ - https://libvirt.org/kbase/virtiofs.html VirtioFsDxe will bind virtio-fs devices, and produce EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them. In the longer term, assuming QEMU will create "bootorder" fw_cfg file entries for virtio-fs devices, booting guest OSes from host-side directories should become possible (dependent on the matching QemuBootOrderLib enhancement). Add the skeleton of the driver. Install EFI_DRIVER_BINDING_PROTOCOL with stub member functions. Install EFI_COMPONENT_NAME2_PROTOCOL with final member functions. This suffices for the DRIVERS command in the UEFI Shell to list the driver with a human-readable name. The file permission model is described immediately in the INF file as a comment block, for future reference. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformBootManagerLib: fix PCI interrupt link (LNKx)Borghorst, Hendrik via groups.io2020-12-181-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue with the current programming of the i440fx PCI Interrupt routing assignment. Explanation by Laszlo Ersek: (1) The rotating pattern is a map: (slot, function) --> (interrupt link) [LNKA..LNKD] (more precisely, it is a pattern from (slot, pin) to (interrupt link), but function<->pin is an identity mapping in the QEMU hardware, so we can just use (slot, function) rather than (slot, pin) on the left hand side. But I digress.) The ACPI _PRT object is generated by QEMU; it describes this map. (2) Another map is (interrupt link) --> { set of possible interrupt numbers, for this link } This map is given by the LNK[A..D] ACPI objects, also given by QEMU. (3) What the firmware is expected to do is: (3a) for each interrupt link, select an *actual* interrupt from the set that's possible for that link, yielding a deterministic map (interrupt link) --> (actual interrupt number) and (3b) for each PCI device/function with an interrupt pin, resolve the (slot, function) --> (interrupt link) --> (actual interrupt number) functional composition, and program the result into the Interrupt Line register of the device. In OVMF, we do not parse the rotating map described under (1) from QEMU's _PRT object. Instead, we duplicate the code. This is not a problem. In OVMF, we also do not parse the map described under (2) from QEMU's ACPI content. Instead, we pick a specific selection (3a) that we "apriori" know satisfies (2). This is also not a problem. OVMF's particular selection is the PciHostIrqs table. ( Table (2) from QEMU is LNKA -> { 5, 10, 11 } LNKB -> { 5, 10, 11 } LNKC -> { 5, 10, 11 } LNKD -> { 5, 10, 11 } and our specific pick in OVMF, in the PciHostIrqs table, is LNKA -> 10 LNKB -> 10 LNKC -> 11 LNKD -> 11 ) In OVMF, we also cover step (3b), in the SetPciIntLine() function. What's missing in OVMF -- and what this patch corrects -- is that we currently fail to program our selection for table (3) into the hardware. We pick a specific LNKx->IRQ# mapping for each interrupt link, and we correctly program the PCI Interrupt Line registers through those link-to-IRQ mappings -- but we don't tell the hardware about the link-to-IRQ mappings. More precisely, we program such a link-to-IRQ mapping table into the hardware that is then not matched by the mapping we use for programming the PCI device/function interrupt lines. As a result, some PCI Interrupt Line registers will have impossible values -- a given (slot, function) may use a particular link, but also report an interrupt number that was never picked for that link. Output of Linux PCI Interrupt Links for i440fx before the patch: [ 0.327305] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11) [ 0.327944] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11) [ 0.328582] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11) [ 0.329208] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11) [ 0.329807] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) after the patch: [ 0.327292] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) [ 0.327934] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.328564] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.329195] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) [ 0.329785] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) Output of Linux PCI Interrupt Links for q35 before the patch: [ 0.307474] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) [ 0.308027] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.308764] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.309310] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) [ 0.309853] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) [ 0.310508] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) [ 0.311051] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) [ 0.311589] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) after the patch: [ 0.301991] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) [ 0.302833] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) [ 0.303354] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) [ 0.303873] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) [ 0.304399] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11) [ 0.304918] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11) [ 0.305436] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11) [ 0.305954] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11) Signed-off-by: Hendrik Borghorst <hborghor@amazon.de> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Message-Id: <8dbedc4c7a1c3fd390aca915270814e3b35e13a5.camel@amazon.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/AmdSev/SecretDxe: make secret location naming genericJames Bottomley2020-12-184-10/+10
| | | | | | | | | | | | It is anticipated that this part of the code will work for both Intel TDX and AMD SEV, so remove the SEV specific naming and change to ConfidentialComputing as a more architecture neutral prefix. Apart from the symbol rename, there are no code changes. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Message-Id: <20201216014146.2229-3-jejb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Change SEV Launch Secret API to be UINT64 for base and sizeJames Bottomley2020-12-181-2/+2
| | | | | | | | | | | | Although the SEV secret location must always be below 4GB, the same is not necessarily true for Intel TDX, so change the configuration table to contain a pair of UINT64 parameters instead of UINT32 so that any X64 location can be represented. Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201216014146.2229-2-jejb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformCI: stick with "ubuntu-18.04" for nowLaszlo Ersek2020-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "vm_image: 'ubuntu-latest'" now refers to Ubuntu Focal (20.04LTS), not Ubuntu Bionic (18.04LTS), according to <https://github.com/actions/virtual-environments/issues/1816>. In Focal, the "qemu" package is a dummy package with no dependencies, and so the actual emulators are not pulled in. Compare: https://packages.ubuntu.com/bionic/qemu https://packages.ubuntu.com/focal/qemu This causes CI runs to fail. It would be best to switch to the "qemu-system" package name, which continues to depend on the emulators: https://packages.ubuntu.com/bionic/qemu-system https://packages.ubuntu.com/focal/qemu-system However, while that package does make the emulators available, the emulators crash. So for now, stick with the previous Ubuntu environment, which continues to be supported, per <https://github.com/actions/virtual-environments/issues/1816>. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201217204049.26817-3-lersek@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration tableJames Bottomley2020-12-146-0/+95
| | | | | | | | | | | | | | Now that the secret area is protected by a boot time HOB, extract its location details into a configuration table referenced by gSevLaunchSecretGuid so the boot loader or OS can locate it before a call to ExitBootServices(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-7-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix indentation of InstallConfigurationTable() args]
* OvmfPkg/AmdSev: assign and reserve the Sev Secret areaJames Bottomley2020-12-144-0/+65
| | | | | | | | | | | | | Create a one page secret area in the MEMFD and reserve the area with a boot time HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-6-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: s/protect/reserve/g in the commit message, at Ard's and James's suggestion]
* OvmfPkg: create a SEV secret area in the AmdSev memfdJames Bottomley2020-12-144-0/+31
| | | | | | | | | | | | | | SEV needs an area to place an injected secret where OVMF can find it and pass it up as a ConfigurationTable. This patch implements the area itself as an addition to the SEV enhanced reset vector table using an additional guid (4c2eb361-7d9b-4cc3-8081-127c90d3d294). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-5-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix typo in "ResetVectorVtf0.asm" comments]
* OvmfPkg/AmdSev: add Grub Firmware Volume PackageJames Bottomley2020-12-1412-10/+2144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used to package up the grub bootloader into a firmware volume where it can be executed as a shell like the UEFI Shell. Grub itself is built as a minimal entity into a Fv and then added as a boot option. By default the UEFI shell isn't built but for debugging purposes it can be enabled and will then be presented as a boot option (This should never be allowed for secure boot in an external data centre but may be useful for local debugging). Finally all other boot options except grub and possibly the shell are stripped and the boot timeout forced to 0 so the system will not enter a setup menu and will only boot to grub. This is done by copying the Library/PlatformBootManagerLib into Library/PlatformBootManagerLibGrub and then customizing it. Boot failure is fatal to try to prevent secret theft. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-4-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: replace local variable initialization with assignment] Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: squash 'OvmfPkg: add "gGrubFileGuid=Grub" to GuidCheck.IgnoreDuplicates', reviewed stand-alone by Phil (msgid <e6eae551-8563-ccfb-5547-7a97da6d46e5@redhat.com>) and Ard (msgid <10aeda37-def6-d9a4-6e02-4c66c1492f57@arm.com>)]
* OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMFJames Bottomley2020-12-142-0/+1283
| | | | | | | | | | | | | | | This commit represents the file copied from OvmfPkgX64 with minor changes to change the build name. This package will form the basis for adding Sev specific features. Since everything must go into a single rom file for attestation, the separated build of code and variables is eliminated. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-3-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDedJames Bottomley2020-12-141-11/+40
| | | | | | | | | | | | Convert the current ES reset block structure to an extensible guid based structure by appending a header and length, which allow for multiple guid based data packets to be inserted. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-2-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Disable EccCheck CI until EccCheck issues are fixedSean Brogan2020-12-141-1/+2
| | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Message-Id: <20201210215640.1260-1-mikuback@linux.microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: Fix various style issuesRebecca Cran2020-11-3015-53/+47
| | | | | | | | | | | | Fix ordering of includes, sources, libraries etc. Remove leading/trailing underscores from include guards. Change INF and DSC version numbers to be decimal. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-6-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Improve style and formatting in BhyveFwCtlLib.hRebecca Cran2020-11-301-12/+12
| | | | | | | | | | | There were some problems with the formatting and style that made the file difficult to read. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-5-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Fix style of BhyveFwCtlLib.infRebecca Cran2020-11-301-3/+2
| | | | | | | | | | Fix the order of libraries and update INF_VERSION to 1.29. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-4-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Improve code style/formatting in BhyveFwCtlLib.cRebecca Cran2020-11-301-67/+69
| | | | | | | | | | | | The code style in Library/BhyveFwCtlLib/BhyveFwCtlLib.c was very inconsistent. Fix it to pass the ECC tool checks by typedef'ing structs, and improve indentation. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-3-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Fix BhyveFwCtlLib build with VS2019Rebecca Cran2020-11-301-25/+25
| | | | | | | | | | | Update BhyveFwCtlLib.c to fix problems with UINT32/UINTN types that prevented Bhyve from building with VS2019. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-2-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/XenPvBlkDxe: add return value if allocting failWenyi Xie2020-11-271-0/+4
| | | | | | | | | | | | | return EFI_OUT_OF_RESOURCES if pool allocating fail. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com> Message-Id: <1606183592-81879-2-git-send-email-xiewenyi2@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: Copy Real16ToFlat32.asm and enable cache in CR0Rebecca Cran2020-11-271-0/+143
| | | | | | | | | | | | | | | | | | | | | | Copy UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm to OvmfPkg/Bhyve/ResetVector/Ia16, with one change, as has also been made in XenResetVector: - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0) With the CD bit set to 1, this has the downside on AMD systems of actually running with the cache disabled, which slows the entire system to a crawl. There's no need for this bit to be set in virtualized environments. This patch reapplies the change from the freebsd uefi-edk2 repo at https://github.com/freebsd/uefi-edk2/commit/08c00f4e8d9e3e469bdc2ce92d3aa839cae7cf17 Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-4-rebecca@bsdio.com>
* OvmfPkg/Bhyve: Add support for the AMD host bridgeRebecca Cran2020-11-272-3/+6
| | | | | | | | | | | On bhyve, either an Intel or AMD host bridge can be specified, with the default being Intel. Both are identical, except the AMD one uses a PCI vendor ID of AMD. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-3-rebecca@bsdio.com>
* OvmfPkg/Bhyve: Add VariablePolicy engine to BhyveRebecca Cran2020-11-271-1/+3
| | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-2-rebecca@bsdio.com>
* OvmfPkg/PlatformCI/.azurepiplines: Use stable release of QEMUMichael D Kinney2020-11-251-1/+1
| | | | | | | | | | | | | | | | | | Install the 2020.08.14 release of QEMU for Windows. The QEMU release from 2020.11.20 is installed into the incorrect directory and is causing EDK II CI failures in the run to shell step. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/BhyveX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-1/+4
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-12-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfXen.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-11-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-10-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgIa32X64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-9-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgIa32.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-8-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VariablePolicy engine to OvmfPkg platformBret Barkelew2020-11-174-0/+19
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Signed-off-by: Bret Barkelew <brbarkel@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: fix build breakage after SEV-ES changesRebecca Cran2020-11-132-2/+3
| | | | | | | | | | Consume the SEV-ES-independent reset vector restored in the previous patch. Use the Null instance of VmgExitLib. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-3-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: detach ResetVector from before the SEV-ES changesRebecca Cran2020-11-133-0/+255
| | | | | | | | | | | | Commits 6995a1b79bab, 8a2732186a53 and 30937f2f98c4 modified all four regular files under "OvmfPkg/ResetVector" with SEV-ES dependencies. These are not relevant for Bhyve. Detach the pre-SEV-ES version of ResetVector for Bhyve. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-2-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg, OvmfPkg: Disable interrupts when using the GHCBTom Lendacky2020-11-103-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit() directly to perform the flash write when running as an SEV-ES guest. If an interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the interrupt handler will generate a #VC, which can overwrite information in the GHCB that QemuFlashPtrWrite() has set. This has been seen with the timer interrupt firing and the CpuExceptionHandlerLib library code, UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ Xcode5ExceptionHandlerAsm.nasm and ExceptionHandlerAsm.nasm reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In general, it is necessary to protect the GHCB whenever it is used, not just in QemuFlashPtrWrite(). Disable interrupts around the usage of the GHCB by modifying the VmgInit() and VmgDone() interfaces: - VmgInit() will take an extra parameter that is a pointer to a BOOLEAN that will hold the interrupt state at the time of invocation. VmgInit() will get and save this interrupt state before updating the GHCB. - VmgDone() will take an extra parameter that is used to indicate whether interrupts are to be (re)enabled. Before exiting, VmgDone() will enable interrupts if that is requested. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Fix erase blocks for SEV-ESTom Lendacky2020-11-101-2/+2
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The original SEV-ES support missed updating the QemuFlashEraseBlock() function to successfully erase blocks. Update QemuFlashEraseBlock() to call the QemuFlashPtrWrite() to be able to successfully perform the commands under SEV-ES. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <309c5317a3107bd0e650be20731842a2e1d4b59a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Set the SwScratch valid bitTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <cc8c8449740d2be0b287e6c69d48bf6cb067c7d8.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SwScratch valid bit for MMIO eventsTom Lendacky2020-11-101-0/+5
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: c45f678a1ea2080344e125dc55b14e4b9f98483d Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <45ccb63c2dadd834e2c47bf10c9e59c6766d7eb6.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SwScratch valid bit for IOIO eventsTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: 0020157a9825e5f5784ff014044f11c0558c92fe Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <f817d034cea37fa78e00e86f61c3445f1208226d.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SW exit fields when performing VMGEXITTom Lendacky2020-11-101-0/+4
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bits for the software exit information fields when performing a VMGEXIT (SwExitCode, SwExitInfo1, SwExitInfo2). Fixes: 61bacc0fa16fd6f595a2c4222425cb6286e19977 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <986e157c13bf33e529b1d16ab1b52e99a74a734f.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Implement new VmgExitLib interfacesTom Lendacky2020-11-102-87/+85
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The VmgExitLib library added two new interfaces, VmgSetOffsetValid() and VmgIsOffsetValid(), that must now be implemented in the OvmfPkg version of the library. Implement VmgSetOffsetValid() and VmgIsOffsetValid() and update existing code, that is directly accessing ValidBitmap, to use the new interfaces. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <939e9dc375e6085bc67942fe9a00ecd4c6b77ecf.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg: enable HttpDynamicCommandVladimir Olovyannikov2020-10-018-0/+20
| | | | | | | | | | | Enable HttpDynamicCommand (Shell command "http") for OvmfPkg platforms. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2857 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Message-Id: <20200722205434.4348-3-vladimir.olovyannikov@broadcom.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove groups.io corruption from Author meta-datum]
* OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwardingLaszlo Ersek2020-09-221-9/+15
| | | | | | | | | | | | | | | | | | | | | | | In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the host-side TLS cipher suite configuration to OVMF. The purpose is to control the permitted ciphers in the guest's UEFI HTTPS boot. This complements the forwarding of the host-side crypto policy from the host to the guest -- the other facet was the set of CA certificates (for which p11-kit patches had been upstreamed, on the host side). Mention the new command line options in "OvmfPkg/README". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200922091827.12617-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: Add RngLib based on TimerLib for CryptoMatthew Carlson2020-09-185-0/+5
| | | | | | | | | | | | | | | | | | | | Updates the DSC's for Ovmf based platforms to add a RngLib that uses the TimerLib. This is due to a later change that adds TimerLib as a dependency for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL previously and it is recommended to switch to a better source of entropy than the system's performance counter. Ref: https://github.com/tianocore/edk2/pull/845 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 04:59:31 +0000