Because of a long-standing bug in shim [0], booting will fail for
distibutions that do not include the fix yet, like Rocky Linux 9.5
and other CentOS-based distibutions. This is cased by the addition
of the EFI_MEMORY_ATTRIBUTE_PROTOCOL in edk2 commit efaa102d00
("UefiCpuPkg: Produce EFI memory attributes protocol") for x86_64.
Even with the fix in shim, issues in commonly shipped versions of GRUB
remain [1].
This is relatively recent, i.e. in the edk2-stable202502 tag, and
since current non-minor distributions are still affected, revert the
problematic commit for now.
Once issues are less common in distributions, an option to support
disabling it (via fw_cfg on the QEMU command line) can still be added
[1]. Then, it can also be nicely documented as a known issue while
giving users guidance.
There already is a similar patch for ARM [2] inherited from the Debian
upstream version.
The problematic commit is EFI_MEMORY_ATTRIBUTE_PROTOCOL was added for x86_64 recently in the
edk2-stable202502 tag. Since current non-minor distributions are still
affected, a revert is done for now.
[0]: c7b3051528
[1]: https://github.com/tianocore/edk2/pull/10667
[2]: ./debian/patches/ArmVirtPkg-disable-the-EFI_MEMORY_ATTRIBUTE-protocol.patch
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[TL: re-export the patch using git format-patch to fix DOS line
endings that EDK2 uses and that might have been lost on mail
transport]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Do not add the two unpack-message-for-orig for the ARM liblto for now,
while they should no be relevant they looked a bit to strange for me
to just plainly ignore.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu>
Tested-by: Markus Frank <m.frank@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
do not bother with dependencies for the split as this is for a
non-supported use-case anyway and we can point users to this fact in
the known issues section of the upgrade notes
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Keep a static build of the last version we supported them (2023.02)
for backward compat in a new separate binary package.
We can make that optional with the next major release and handle
affected VMs in pve8to9.
Signed-off-by: Thomas Lamprecht <t.lamprecht@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>
