Colin Watson [Thu, 28 Feb 2019 09:32:00 +0000 (09:32 +0000)]
util: Detect more I/O errors
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.
James Clarke [Tue, 26 Feb 2019 18:34:22 +0000 (18:34 +0000)]
osdep/freebsd: Fix partition calculation for EBR entries
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.
Steve McIntyre [Tue, 26 Feb 2019 14:14:17 +0000 (14:14 +0000)]
Fall back to arm-uboot if booted using EFI but -efi is missing
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.)
Steve McIntyre [Mon, 11 Feb 2019 02:42:34 +0000 (02:42 +0000)]
grub-install: Check for arm-efi as a default target
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
Leif Lindholm [Thu, 21 Feb 2019 10:15:08 +0000 (10:15 +0000)]
arm64/efi: Fix grub_efi_get_ram_base()
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
Colin Watson [Tue, 26 Feb 2019 12:46:25 +0000 (12:46 +0000)]
Improve handling of /dev/disk/by-id/ changes
Preserve previous answer to grub-pc/install_devices if we have to ask
grub-pc/install_devices_disks_changed and the user chooses not to
install to any devices, so that we can recover from temporary bugs that
cause /dev/disk/by-id/ paths to change.
Ideally this would also include explanatory text in the debconf
template, but it's a bit late in the buster release cycle for new
translatable text. I've left an XXX comment for the time being.
Colin Watson [Tue, 26 Feb 2019 09:55:35 +0000 (09:55 +0000)]
Remove old /dev/disk/by-id/ migration code
Remove code to migrate grub-pc/install_devices to persistent device
names under /dev/disk/by-id/. This migration happened in
1.98+20100702-1, which was in squeeze (four stable releases ago), so we
no longer need to carry around this complex code.
Hervé Werner [Mon, 28 Jan 2019 16:24:23 +0000 (17:24 +0100)]
Fix setup on Secure Boot systems where cryptodisk is in use
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.
ieee1275: Include a.out header in assembly of sparc64 boot loader
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
Jeroen Dekkers [Sat, 12 Jan 2019 20:02:18 +0000 (21:02 +0100)]
at_keyboard: initialize keyboard in module init if keyboard is ready
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.
Alexander Graf [Mon, 28 Jan 2019 13:35:29 +0000 (14:35 +0100)]
mkimage: Clarify file alignment in efi case
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
Alexander Graf [Mon, 28 Jan 2019 13:35:28 +0000 (14:35 +0100)]
mkimage: Align efi sections on 4k boundary
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
Jeroen Dekkers [Sat, 12 Jan 2019 20:02:18 +0000 (21:02 +0100)]
at_keyboard: initialize keyboard in module init if keyboard is ready
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.
Alexander Graf [Sun, 23 Dec 2018 02:52:07 +0000 (03:52 +0100)]
mkimage: arm64-efi: Align first section to page
In order to enforce NX semantics on non-code pages, UEFI firmware
may require that all code is EFI_PAGE_SIZE (4k) aligned. A similar
change has recently been applied to edk2 to accomodate for the same
fact:
Alexander Graf [Sun, 23 Dec 2018 02:52:06 +0000 (03:52 +0100)]
mkimage: Simplify header size logic
For EFI images, we always have the following layout:
[PE header]
[padding]
[first section (which also is the entry point)]
Currently there are 2 places where we define how big header+padding are:
in the .vaddr_offset member of our target image definition struct as well
as in code in grub_install_generate_image().
Remove the latter, so that we only have a single place to modify if we
need to change the padding.
Signed-off-by: Hans van Kranenburg <hans@knorrie.org> 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=a40b219e269ac407c10a569ce6b0c5d7f419d127
Bug-Debian: https://bugs.debian.org/776450
Last-Update: 2019-01-07
Juergen Gross [Fri, 7 Dec 2018 12:11:42 +0000 (13:11 +0100)]
xen: Init memory regions for PVH
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
Juergen Gross [Fri, 7 Dec 2018 12:11:37 +0000 (13:11 +0100)]
xen: Add basic hooks for PVH in current code
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
Juergen Gross [Fri, 7 Dec 2018 12:11:34 +0000 (13:11 +0100)]
xen: Rearrange xen/init.c to prepare it for Xen PVH mode
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
Juergen Gross [Fri, 7 Dec 2018 12:11:33 +0000 (13:11 +0100)]
xen: Add some dummy headers for PVH mode
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
Juergen Gross [Fri, 7 Dec 2018 12:11:32 +0000 (13:11 +0100)]
xen: Prepare common code for Xen PVH support
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
Juergen Gross [Fri, 7 Dec 2018 12:11:29 +0000 (13:11 +0100)]
xen: Add some Xen headers
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
Colin Watson [Sat, 5 Jan 2019 18:15:10 +0000 (18:15 +0000)]
Avoid spurious ucf prompts
Keep track of the previous version of /usr/share/grub/default/grub and
set UCF_FORCE_CONFFOLD=1 when running ucf if it hasn't changed; ucf
can't figure this out for itself since we apply debconf-based
customisations on top of the template configuration file.
grub-core/loader/efi/fdt.c: do not copy random memory
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
Matthew Garrett [Wed, 5 Dec 2018 23:07:21 +0000 (15:07 -0800)]
Don't enforce Shim signature validation if Secure Boot is disabled
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.
Michael Chang [Mon, 26 Mar 2018 08:52:34 +0000 (16:52 +0800)]
Fix packed-not-aligned error on GCC 8
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
Leif Lindholm [Mon, 11 Jun 2018 16:24:59 +0000 (17:24 +0100)]
efi/fdt: Set address/size cells to 2 for empty tree
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/
efi: Restrict arm/arm64 linux loader initrd placement
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.
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.
efi: Add grub_efi_get_ram_base() function for arm64
Since ARM platforms do not have a common memory map, add a helper
function that finds the lowest address region with the EFI_MEMORY_WB
attribute set in the UEFI memory map.
Required for the arm64 efi linux loader to restrict the initrd
location to where it will be accessible by the kernel at runtime.
Leif Lindholm [Thu, 1 Feb 2018 18:18:56 +0000 (18:18 +0000)]
arm: make linux.h safe to include for non-native builds
<grub/machine/loader.h> (for machine arm/efi) and
<grub/machine/kernel.h> (for machine arm/coreboot) will not always
resolve (and will likely not be valid to) if pulled in when building
non-native commands, such as host tools or the "file" command.
So explicitly include them with their expanded pathnames.
Leif Lindholm [Thu, 1 Feb 2018 18:18:50 +0000 (18:18 +0000)]
Make arch-specific linux.h include guards architecture unique
Replace uses of GRUB_LINUX_MACHINE_HEADER and GRUB_LINUX_CPU_HEADER
with GRUB_<arch>_LINUX_HEADER include guards to prevent issues when
including more than one of them.
Leif Lindholm [Thu, 3 Aug 2017 10:04:32 +0000 (11:04 +0100)]
efi: change heap allocation type to GRUB_EFI_LOADER_CODE
With upcoming changes to EDK2, allocations of type EFI_LOADER_DATA may
not return regions with execute ability. Since modules are loaded onto
the heap, change the heap allocation type to GRUB_EFI_LOADER_CODE in
order to permit execution on systems with this feature enabled.
Leif Lindholm [Thu, 3 Aug 2017 10:04:24 +0000 (11:04 +0100)]
efi: move fdt helper library
There is nothing ARM64 (or even ARM) specific about the efi fdt helper
library, which is used for locating or overriding a firmware-provided
devicetree in a UEFI system - so move it to loader/efi for reuse.
Move the fdtload.h include file to grub/efi and update path to
efi/fdtload.h in source code referring to it.
projects / grub2.git / log