In this case, we need both the signed shim as /EFI/BOOT/BOOTXXX.EFI
and signed Grub as /EFI/BOOT/grubXXX.efi.
Also install the BOOTXXX.CSV into /EFI/debian, and FBXXX.EFI into
/EFI/BOOT/ so that it can work when needed (*iff* we're updating the
NVRAM).
[cjwatson: Refactored also_install_removable somewhat for brevity and so
that we're using consistent case-insensitive logic.]
Bug-Debian: https://bugs.debian.org/930531
Last-Update: 2019-06-14
Patch-Name: grub-install-removable-shim.patch
Gbp-Pq: Name grub-install-removable-shim.patch
The arm relocation code has a manual special case for EFI binaries to
add the natural alignment to its own relocation awareness.
Since commit a51f953f4e ("mkimage: Align efi sections on 4k
boundary") we changed that alignment from 0x400 to 0x1000 bytes. Reflect
the change in that branch that we forgot as well.
This fixes running 32bit arm grub efi binaries for me again.
Fixes: a51f953f4e ("mkimage: Align efi sections on 4k boundary")
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reported-by: Steve McIntyre <steve@einval.com>
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
Bug-Debian: https://bugs.debian.org/927269
Origin: other, https://lists.gnu.org/archive/html/grub-devel/2019-04/msg00132.html
Last-Update: 2019-05-03
Patch-Name: arm-align-section-alignment-with-manual-reloc-offset.patch
Gbp-Pq: Name arm-align-section-alignment-with-manual-reloc-offset.patch
When creating T32->A32 transition jumps, the relocation code in grub
will generate trampolines. These trampolines live in the .data section
of our PE binary which means they are not marked as executable.
This misbehavior was unmasked by commit a51f953f4e ("mkimage: Align
efi sections on 4k boundary") which made the X/NX boundary more obvious
because everything became page aligned.
To put things into proper order, let's move the arm trampolines into the
.text section instead. That way everyone knows they are executable.
Fixes: a51f953f4e ("mkimage: Align efi sections on 4k boundary")
Reported-by: Julien ROBIN <julien.robin28@free.fr>
Reported-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
Bug-Debian: https://bugs.debian.org/927269
Origin: other, https://lists.gnu.org/archive/html/grub-devel/2019-04/msg00131.html
Last-Update: 2019-05-03
Patch-Name: arm-move-trampolines-into-code-section.patch
Gbp-Pq: Name arm-move-trampolines-into-code-section.patch
Some UEFI firmware is easily provoked into running out of space in its
variable storage. This is usually due to certain kernel drivers (e.g.
pstore), but regardless of the cause it can cause grub-install to fail
because it currently asks efibootmgr to delete and re-add entries, and
the deletion often doesn't result in an immediate garbage collection.
Writing variables frequently also increases wear on the NVRAM which may
have limited write cycles. For these reasons, it's desirable to find a
way to minimise writes while still allowing grub-install to ensure that
a suitable boot entry exists.
Unfortunately, efibootmgr doesn't offer an interface that would let
grub-install do this. It doesn't in general make very much effort to
minimise writes; it doesn't allow modifying an existing Boot* variable
entry, except in certain limited ways; and current versions don't have a
way to export the expected variable data so that grub-install can
compare it to the current data. While it would be possible (and perhaps
desirable?) to add at least some of this to efibootmgr, that would still
leave the problem that there isn't a good upstreamable way for
grub-install to guarantee that it has a new enough version of
efibootmgr. In any case, it's cumbersome and slow for grub-install to
have to fork efibootmgr to get things done.
Fortunately, a few years ago Peter Jones helpfully factored out a
substantial part of efibootmgr to the efivar and efiboot libraries, and
so it's now possible to have grub-install use those directly. We still
have to use some code from efibootmgr, but much less than would
previously have been necessary.
grub-install now reuses existing boot entries where possible, and avoids
writing to variables when the new contents are the same as the old
contents. In the common upgrade case where nothing needs to change, it
no longer writes to NVRAM at all. It's also now slightly faster, since
using libefivar is faster than forking efibootmgr.
Fixes Debian bug #891434.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Bug-Debian: https://bugs.debian.org/891434
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
Last-Update: 2019-03-23
Patch-Name: efi-variable-storage-minimise-writes.patch
Gbp-Pq: Name efi-variable-storage-minimise-writes.patch
The sparse inode metadata format became a mkfs.xfs default in
xfsprogs-4.16.0, and such filesystems are now rejected by grub as
containing an incompatible feature.
In essence, this feature allows xfs to allocate inodes into fragmented
freespace. (Without this feature, if xfs could not allocate contiguous
space for 64 new inodes, inode creation would fail.)
In practice, the disk format change is restricted to the inode btree,
which as far as I can tell is not used by grub. If all you're doing
today is parsing a directory, reading an inode number, and converting
that inode number to a disk location, then ignoring this feature
should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED
I did some brief testing of this patch by hacking up the regression
tests to completely fragment freespace on the test xfs filesystem, and
then write a large-ish number of inodes to consume any existing
contiguous 64-inode chunk. This way any files the grub tests add and
traverse would be in such a fragmented inode allocation. Tests passed,
but I'm not sure how to cleanly integrate that into the test harness.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Chris Murphy <lists@colorremedies.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=cda0a857dd7a27cd5d621747464bfe71e8727fff
Bug-Debian: https://bugs.debian.org/924760
Last-Update: 2019-03-20
Patch-Name: xfs-sparse-inodes.patch
Gbp-Pq: Name xfs-sparse-inodes.patch
Many of GRUB's utilities don't check anywhere near all the possible
write errors. For example, if grub-install runs out of space when
copying a file, it won't notice. There were missing checks for the
return values of write, fflush, fsync, and close (or the equivalents on
other OSes), all of which must be checked.
I tried to be consistent with the existing logging practices of the
various hostdisk implementations, but they weren't entirely consistent
to start with so I used my judgement. The result at least looks
reasonable on GNU/Linux when I provoke a write error:
Installing for x86_64-efi platform.
grub-install: error: cannot copy `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' to `/boot/efi/EFI/debian/grubx64.efi': No space left on device.
There are more missing checks in other utilities, but this should fix
the most critical ones.
Bug-Debian: https://bugs.debian.org/922741
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-02/msg00125.html
Last-Update: 2019-02-28
Patch-Name: util-check-errors.patch
Gbp-Pq: Name util-check-errors.patch
For EBR partitions, "start" is the relative starting sector of the EBR
header itself, whereas "offset" is the relative starting byte of the
partition's contents, excluding the EBR header and any padding. Thus we
must use "offset", and divide by the sector size to convert to sectors.
Bug-Debian: https://bugs.debian.org/923253
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-02/msg00124.html
Last-Update: 2019-02-26
Patch-Name: freebsd-ebr-partition-offset.patch
Gbp-Pq: Name freebsd-ebr-partition-offset.patch
It may be possible, particularly in recovery situations, to be booted
using EFI on ARM when only the arm-uboot target is installed. There's
nothing actually stopping us installing arm-uboot from an EFI
environment, and it's better than returning a confusing error.
(When convenient, this patch should be merged with
install_efi_fallback.patch.)
Forwarded: no
Last-Update: 2019-02-26
Patch-Name: install_efi_fallback_arm.patch
Gbp-Pq: Name install_efi_fallback_arm.patch
Much like on x86, we can work out if the system is running on top
of EFI firmware. If so, return "arm-efi". If not, fall back to
"arm-uboot" as previously.
Heavily inspired by the existing code for x86.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=082fd84d525f8d6602f892160b77c0a948308a78
Bug-Debian: https://bugs.debian.org/922104
Last-Update: 2019-02-26
Patch-Name: grub-install-arm-default-target.patch
Gbp-Pq: Name grub-install-arm-default-target.patch
grub_efi_get_ram_base() looks for the lowest available RAM address by
traversing the memory map, comparing lowest address found so far.
Due to a brain glitch, that "so far" was initialized to GRUB_UINT_MAX -
completely preventing boot on systems without RAM below 4GB.
Change the initial value to GRUB_EFI_MAX_USABLE_ADDRESS, as originally
intended.
Reported-by: Steve McIntyre <93sam@debian.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=566b16a0dc23d72357d2d75b781d3c7895b8a234
Last-Update: 2019-02-26
Patch-Name: arm64-fix-grub_efi_get_ram_base.patch
Gbp-Pq: Name arm64-fix-grub_efi_get_ram_base.patch
On full-encrypted systems, including /boot, the current code omits
cryptodisk commands needed to open the drives if Secure Boot is enabled.
This prevents grub2 from reading any further configuration residing on
the encrypted disk.
This patch fixes this issue by adding the needed "cryptomount" commands in
the load.cfg file that is then copied in the EFI partition.
Bug-Debian: https://bugs.debian.org/917117
Last-Update: 2019-02-10
Patch-Name: uefi-secure-boot-cryptomount.patch
Gbp-Pq: Name uefi-secure-boot-cryptomount.patch
Recent versions of binutils dropped support for the a.out and COFF
formats on sparc64 targets. Since the boot loader on sparc64 is
supposed to be an a.out binary and the a.out header entries are
rather simple to calculate in our case, we just write the header
ourselves instead of relying external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Bug-Debian: https://bugs.debian.org/921249
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-02/msg00014.html
Last-Update: 2019-02-09
Patch-Name: sparc64-aout-fix.patch
Gbp-Pq: Name sparc64-aout-fix.patch
The change in 0c62a5b2 caused at_keyboard to fail on some
machines. Immediately initializing the keyboard in the module init if
the keyboard is ready makes the problem go away.
Bug-Debian: https://bugs.debian.org/741464
Last-Update: 2019-02-09
Patch-Name: at-keyboard-module-init.patch
Gbp-Pq: Name at-keyboard-module-init.patch
There are a few spots in the PE generation code for EFI binaries that uses
the section alignment rather than file alignment, even though the alignment
is really only file bound.
Replace those cases with the file alignment constant instead.
Reported-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9223eff8f8025511938c7eec908d60bdaa74106a
Bug-Debian: https://bugs.debian.org/919012
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1812317
Last-Update: 2019-02-09
Patch-Name: mkimage_clarify_file_alignment_efi.patch
Gbp-Pq: Name mkimage_clarify_file_alignment_efi.patch
There is UEFI firmware popping up in the wild now that implements stricter
permission checks using NX and write protect page table entry bits.
This means that firmware now may fail to load binaries if its individual
sections are not page aligned, as otherwise it can not ensure permission
boundaries.
So let's bump all efi section alignments up to 4k (EFI page size). That way
we will stay compatible going forward.
Unfortunately our internals can't deal very well with a mismatch of alignment
between the virtual and file offsets, so we have to also pad our target
binary a bit.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a51f953f4ee87cbfbf25a7df564304c5e9fea6a0
Bug-Debian: https://bugs.debian.org/919012
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1812317
Last-Update: 2019-02-09
Patch-Name: mkimage_Align_efi_sections_on_4k_boundary.patch
Gbp-Pq: Name mkimage_Align_efi_sections_on_4k_boundary.patch
The efi-arm case was defining its own header size calculation, even though it's
100% identical to the common EFI32_HEADER_SIZE definition.
So let's clean it up to use the common define.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Julien ROBIN <julien.robin28@free.fr>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e347f40c1af2457a634af71e3cc75e851c641847
Bug-Debian: https://bugs.debian.org/919012
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1812317
Last-Update: 2019-02-09
Patch-Name: mkimage_arm-efi_Use_EFI32_HEADER_SIZE.patch
Gbp-Pq: Name mkimage_arm-efi_Use_EFI32_HEADER_SIZE.patch
In order to avoid using plain integers for the ELF notes use the
available Xen include instead.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9bce25213a44553c71527776f65fabc3b729c2f3
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-elfnote-defines.patch
Gbp-Pq: Name xen-pvh-elfnote-defines.patch
Add all usable memory regions to grub memory management and add the
needed mmap iterate code, which will be used by grub core (e.g.
grub-core/lib/relocator.c or grub-core/mmap/mmap.c).
As we are running in 32-bit mode don't add memory above 4GB.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=1d2473a024a9e1f46a7caa75d5c8186ed2cdb6e1
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-init-memory-regions.patch
Gbp-Pq: Name xen-pvh-init-memory-regions.patch
Initialize the needed Xen specific data. This is:
- the Xen start of day page containing the console and Xenstore ring
page PFN and event channel
- the grant table
- the shared info page
Write back the possibly modified memory map to the hypervisor in case
the guest is reading it from there again.
Set the RSDP address for the guest from the start_info page passed
as boot parameter.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4c9b4a7c92c9373315fd8b0f8f889275814bba41
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-setup-data.patch
Gbp-Pq: Name xen-pvh-setup-data.patch
Retrieve the memory map from the hypervisor and normalize it to contain
no overlapping entries and to be sorted by address.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=2b7a21afd319b829941a928f5763e017d1cc2951
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-get-memory-map.patch
Gbp-Pq: Name xen-pvh-get-memory-map.patch
Add the needed code to setup the hypercall page for calling into the
Xen hypervisor.
Import the XEN_HVM_DEBUGCONS_IOPORT define from Xen unstable into
include/xen/arch-x86/xen.h
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=da81e42a7ccb545513368ec7488cdf5019c1c2ba
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-setup-hypercall-page.patch
Gbp-Pq: Name xen-pvh-setup-hypercall-page.patch
Add the hooks to current code needed for Xen PVH. They will be filled
with code later when the related functionality is being added.
loader/i386/linux.c needs to include machine/kernel.h now as it needs
to get GRUB_KERNEL_USE_RSDP_ADDR from there. This in turn requires to
add an empty kernel.h header for some i386 platforms (efi, coreboot,
ieee1275, xen) and for x86_64 efi.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: backport, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0b3e4eb2d2e1875e6045e838962f769f2ce161dd
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-basic-hooks.patch
Gbp-Pq: Name xen-pvh-basic-hooks.patch
include/grub/offsets.h needs some defines for Xen PVH mode.
Add them. While at it line up the values in the surrounding lines to
start at the same column.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=53a92dea8b675afb3f46aed15c04528695d46d59
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-offsets.patch
Gbp-Pq: Name xen-pvh-offsets.patch
grub_xen_ptr2mfn() returns the machine frame number for a given pointer
value. For Xen-PVH guests this is just the PFN. Add the PVH specific
variant.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=3b8d09c7742a1890eadad6987852c82947ea5d4a
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-ptr2mfn.patch
Gbp-Pq: Name xen-pvh-ptr2mfn.patch
Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support
to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN
as it will not be used when running as PVH.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=bec9edf53f4d0b629a52a7d1145f38f88df8dd1d
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-rearrange-init.patch
Gbp-Pq: Name xen-pvh-rearrange-init.patch
With Xen PVH mode adding a new machine type the machine related headers
need to be present for the build to succeed. Most of the headers just
need to include the related common i386 headers. Add those to the tree.
Note that xen_pvh/int.h needs to include pc/int_types.h instead of
pc/int.h in order to avoid the definition of grub_bios_interrupt().
xen_pvh/memory.h needs to include coreboot/memory.h (like some other
<machine>/memory.h do as well) as this contains just the needed stubs.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=408de833bbd1ccad39ad439eaf3cddd528b039b5
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-add-dummy-headers.patch
Gbp-Pq: Name xen-pvh-add-dummy-headers.patch
Some common code needs to be special cased for Xen PVH mode. This hits
mostly Xen PV mode specific areas.
Split include/grub/i386/pc/int_types.h off from
include/grub/i386/pc/int.h to support including this file later from
xen_pvh code without the grub_bios_interrupt definition.
Move definition of struct grub_e820_mmap_entry from
grub-core/mmap/i386/pc/mmap.c to include/grub/i386/memory.h in order
to make it usable from xen_pvh code.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=fc9d47ead56365c3335bb42cf651008c9ac1f494
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-prepare-common-code.patch
Gbp-Pq: Name xen-pvh-prepare-common-code.patch
Initialize the grant tab in a dedicated function. This will enable
using it for PVH guests, too.
Call the new function from grub_machine_init() as this will later
be common between Xen PV and Xen PVH mode.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c84927272cea59084ad5b0705c55547e8c85b28d
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-refactor-grant-tab-init.patch
Gbp-Pq: Name xen-pvh-refactor-grant-tab-init.patch
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d170be42f12b0b2ab91d8d943d7b0bf563c906dd
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-rsdp-boot-params.patch
Gbp-Pq: Name xen-pvh-rsdp-boot-params.patch
In order to support grub2 in Xen PVH environment some additional Xen
headers are needed as grub2 will be started in PVH mode requiring to
use several HVM hypercalls and structures.
Add the needed headers from Xen 4.10 being the first Xen version with
full (not only experimental) PVH guest support.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=9118effd1b1fb67d82168b37cf6dd1142feced3b
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Patch-Name: xen-pvh-add-headers.patch
Gbp-Pq: Name xen-pvh-add-headers.patch
We should not try to copy any memory area which is outside of the original
fdt. If this extra memory is controlled by a hypervisor this might end
with a crash.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Origin: other, https://lists.gnu.org/archive/html/grub-devel/2018-12/msg00042.html
Last-Update: 2018-12-21
Patch-Name: efi-fdt-do-not-copy-random-memory.patch
Gbp-Pq: Name efi-fdt-do-not-copy-random-memory.patch
The linuxefi command fails if used on a system without shim, even if
Secure Boot is disabled. There's no need to do the validation if we're
not in Secure Boot mode (an attacker could just boot a modified grub),
so skip this to make it easier to use the Linux EFI entry point even on
non-Secure Boot systems.
Last-Update: 2018-12-07
Patch-Name: linuxefi-skip-validation-without-secure-boot.patch
Gbp-Pq: Name linuxefi-skip-validation-without-secure-boot.patch
When building with GCC 8, there are several errors regarding packed-not-aligned.
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
This patch fixes the build error by cleaning up the ambiguity of placing
aligned structure in a packed one. In "struct grub_btrfs_time" and "struct
grub_gpt_part_type", the aligned attribute seems to be superfluous, and also
has to be packed, to ensure the structure is bit-to-bit mapped to the format
laid on disk. I think we could blame to copy and paste error here for the
mistake. In "struct efi_variable", we have to use grub_efi_packed_guid_t, as
the name suggests. :)
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Michael Chang <mchang@suse.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=563b1da6e6ae7af46cc8354cadb5dab416989f0a
Bug-Debian: https://bugs.debian.org/915735
Last-Update: 2018-10-07
Patch-Name: gcc-8-packed-not-aligned.patch
Gbp-Pq: Name gcc-8-packed-not-aligned.patch
This updates the non-upstream loader/i386/efi/linux.c to build
correctly with the patches in this branch appled.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Bug-Debian: https://bugs.debian.org/907596
Bug-Debian: https://bugs.debian.org/909420
Bug-Debian: https://bugs.debian.org/915091
Last-Update: 2018-12-06
Patch-Name: linuxefi-update-to-new-interfaces.patch
Gbp-Pq: Name linuxefi-update-to-new-interfaces.patch
When booting an arm* system on UEFI with an empty device tree (currently
only when hardware description comes from ACPI), we don't currently set
default to 1 cell (32 bits).
Set both of these properties, to 2 cells (64 bits), to resolve issues
with kexec on some platforms.
This change corresponds with linux kernel commit ae8a442dfdc4
("efi/libstub/arm*: Set default address and size cells values for an empty dtb")
and ensures booting through grub does not behave differently from booting
the stub loader directly.
See also https://patchwork.kernel.org/patch/9561201/
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=347210a5d5ce655b95315f320faa515afb723c11
Bug-Debian: https://bugs.debian.org/915091
Last-Update: 2018-12-06
Patch-Name: efi-fdt-set-address-size-cells-to-2-for-empty-tree.patch
Gbp-Pq: Name efi-fdt-set-address-size-cells-to-2-for-empty-tree.patch
To be able to resuse the prop_entry_size macro, move it to
<grub/fdt.h> and rename it grub_fdt_prop_entry_size.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: backport, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e93fd6b776a7e6cef36c445d00436e5a23cfeba5
Bug-Debian: https://bugs.debian.org/915091
Last-Update: 2018-12-06
Patch-Name: fdt-move-prop_entry_size-to-fdt-h.patch
Gbp-Pq: Name fdt-move-prop_entry_size-to-fdt-h.patch
The 32-bit arm Linux kernel is built as a zImage, which self-decompresses
down to near start of RAM. In order for an initrd/initramfs to be
accessible, it needs to be placed within the first ~768MB of RAM.
The initrd loader built into the kernel EFI stub restricts this down to
512MB for simplicity - so enable the same restriction in grub.
For arm64, the requirement is within a 1GB aligned 32GB window also
covering the (runtime) kernel image. Since the EFI stub loader itself
will attempt to relocate to near start of RAM, force initrd to be loaded
completely within the first 32GB of RAM.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a2f26adfef2fc8a7d7392c3704031df4624c67b0
Bug-Debian: https://bugs.debian.org/907596
Bug-Debian: https://bugs.debian.org/915091
Last-Update: 2018-12-06
Patch-Name: efi-restrict-arm-arm64-linux-loader-initrd-placement.patch
Gbp-Pq: Name efi-restrict-arm-arm64-linux-loader-initrd-placement.patch
The 32-bit arm efi port now shares the 64-bit linux loader, so delete
the now unused bits from the 32-bit linux loader.
This in turn leaves the grub-core/kern/arm/efi/misc.c unused, so
delete that too.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: backport, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=77808dd66bda72ff14873bcd701ec25a0db1dfee
Bug-Debian: https://bugs.debian.org/907596
Last-Update: 2018-12-06
Patch-Name: arm-delete-unused-efi-support-from-loader-arm.patch
Gbp-Pq: Name arm-delete-unused-efi-support-from-loader-arm.patch
The arm64 and arm linux kernel EFI-stub support presents pretty much
identical interfaces, so the same linux loader source can be used for
both architectures.
Switch 32-bit ARM UEFI platforms over to the existing EFI-stub aware
loader initially developed for arm64.
This *WILL* stop non-efistub Linux kernels from booting on arm-efi.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d0c070179d4d78c297364e41ece54fd7755c4b58
Bug-Debian: https://bugs.debian.org/907596
Bug-Debian: https://bugs.debian.org/909420
Last-Update: 2018-12-06
Patch-Name: arm-efi-switch-to-arm64-linux-loader.patch
Gbp-Pq: Name arm-efi-switch-to-arm64-linux-loader.patch
