since the shell allows circumvention of Secure Boot restrictions, for example
via raw memory access or execution of scripts on the ESP.
see Links in the patch for details.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
(cherry picked from commit 334229c409)
CVE-2023-45229-CVE-2023-45237, taken from upstream announcement/issue at
https://bugzilla.tianocore.org/show_bug.cgi?id=4518
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
(cherry-picked from commit fee1be4819)
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
by limiting the phys-bits to 46 instead of 47. On Ubuntu 18.04 with
kernel 4.15, using 47 leads to a strange issue where initialization of
VirtIO devices would fail.
Reported in the community forum:
https://forum.proxmox.com/threads/127410/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> Continue to allow bootloaders to execute memory allocated as
> EFI_LOADER_DATA until GRUB fixes are more generally available.
> (Closes: #1025656)
-- a0be41b75c
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Commit 4cb94f20b0 ("OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*") in
the edk2 submodule made the switch from hard coded values for the
SMBIOS type 0 table to using those defined in the PCD (Platform
Configuration Database). But this changed the value for the vendor
from "EFI Development Kit II / OVMF" to "EDK II" and made version and
release date "unknown". This can cause problems for hardware keys[0],
and the missing date can make Windows unhappy[1].
The PCD information can be specified during build. For the vendor,
just revert to the hardcoded value from before. This should be enough
to resolve the issue in [0]. For version and date, use sensible values
gathered from the build variables. The date format is mm/dd/yyyy while
the version is free-form according to [2], section 7.1.
[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=4625
[1]: https://edk2.groups.io/g/devel/message/100922
[2]: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
It is not maintained anymore and got disabled by default in upstream
commit 57783adfb5 ("OvmfPkg: Change default to disable MptScsi and
PvScsi"). Re-enable it to preserve backwards compatibility in Proxmox
VE.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
this is mostly done to secure against a future change of the default
march that may come from the x86-64-v* microarchitecture level [0]
concept that is currently being developed and by some more bleeding
edge distros even already adopted.
[0]: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit 862ea6e836 ("OvmfPkg: change qemu default resolution to
1280x800") made our patch that changed it to 1024x768 obsolete.
Note that QEMU is planning to change their default from 1024x768 to
1280x800 in QEMU 7.0, so that's where that new value is coming from.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Among other thing this now ships OVMF code/vars with secureboot and
MS keys enrolled, allowing Win11 final to get installed and secure
boot support in general.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
