<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.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use kernel header struct and magic definition to align (and coexist) with
i386/arm64 ports.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename GRUB_LINUX_MAGIC_SIGNATURE GRUB_LINUX_I386_MAGIC_SIGNATURE,
to be usable in code that supports more than one image type.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI page definitions and macros are generic and should not be confined
to arm64 headers - so move to efi/memory.h.
Also add EFI_PAGE_SIZE macro.
Update loader sources to reflect new header location.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The CRC implementation imported from libgcrypt 1.5.3 is arguably
non-free, due to being encumbered by the restrictive Internet Society
licence on RFCs (see e.g. https://wiki.debian.org/NonFreeIETFDocuments).
Fortunately, libgcrypt has since replaced it with a version that is both
reportedly better-optimised and doesn't suffer from this encumbrance.
The ideal solution would be to update to a new version of libgcrypt, and
I spent some time trying to do that. However, util/import_gcry.py
requires complex modifications to cope with the new version, and I
stalled part-way through; furthermore, GRUB's libgcrypt tree already
contains some backports of upstream changes. Rather than allowing the
perfect to be the enemy of the good, I think it's best to backport this
single change to at least sort out the licensing situation. Doing so
won't make things any harder for a future wholesale upgrade.
This commit is mostly a straightforward backport of
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=06e122baa3321483a47bbf82fd2a4540becfa0c9,
but I also imported bufhelp.h from libgcrypt 1.7.0 (newer versions
required further changes elsewhere).
I've tested that "hashsum -h crc32" still produces correct output for a
variety of files on both i386-pc and x86_64-emu targets.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add NVMe support within ofpath.
The Open Firmware text representation for a NVMe device contains the
Namespace ID. An invalid namespace ID is one whose value is zero or whose
value is greater than the value reported by the Number of Namespaces (NN)
field in the Identify Controller data structure. At the moment only a
single Namespace is supported, therefore the value is currently hard coded
to one.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The definition of bpb's num_total_sectors_16 and num_total_sectors_32
is that either the 16-bit field is non-zero and is used (in which case
eg mkfs.fat sets the 32-bit field to zero), or it is zero and the
32-bit field is used. Therefore, a BPB is invalid only if *both*
fields are zero; having one field as zero and the other as non-zero is
the case to be expected. (Indeed, according to Microsoft's specification
one of the fields *must* be zero, and the other non-zero.)
This affects all users of grub_chainloader_patch_bpb which are in
chainloader.c, freedos.c, and ntldr.c
Some descriptions of the semantics of these two fields:
https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
The old 2-byte fields "total number of sectors" and "number of
sectors per FAT" are now zero; this information is now found in
the new 4-byte fields.
(Here given in the FAT32 EBPB section but the total sectors 16/32 bit
fields semantic is true of FAT12 and FAT16 too.)
https://wiki.osdev.org/FAT#BPB_.28BIOS_Parameter_Block.29
19 | 2 | The total sectors in the logical volume. If this value is 0,
it means there are more than 65535 sectors in the volume, and the actual
count is stored in "Large Sectors (bytes 32-35).
32 | 4 | Large amount of sector on media. This field is set if there
are more than 65535 sectors in the volume.
(Doesn't specify what the "large" field is set to when unused, but as
mentioned mkfs.fat sets it to zero then.)
https://technet.microsoft.com/en-us/library/cc976796.aspx
0x13 | WORD | 0x0000 |
Small Sectors . The number of sectors on the volume represented in 16
bits (< 65,536). For volumes larger than 65,536 sectors, this field
has a value of zero and the Large Sectors field is used instead.
0x20 | DWORD | 0x01F03E00 |
Large Sectors . If the value of the Small Sectors field is zero, this
field contains the total number of sectors in the FAT16 volume. If the
value of the Small Sectors field is not zero, the value of this field
is zero.
https://staff.washington.edu/dittrich/misc/fatgen103.pdf page 10
BPB_TotSec16 | 19 | 2 |
This field is the old 16-bit total count of sectors on the volume.
This count includes the count of all sectors in all four regions of the
volume. This field can be 0; if it is 0, then BPB_TotSec32 must be
non-zero. For FAT32 volumes, this field must be 0. For FAT12 and
FAT16 volumes, this field contains the sector count, and
BPB_TotSec32 is 0 if the total sector count “fits” (is less than
0x10000).
BPB_TotSec32 | 32 | 4 |
This field is the new 32-bit total count of sectors on the volume.
This count includes the count of all sectors in all four regions of the
volume. This field can be 0; if it is 0, then BPB_TotSec16 must be
non-zero. For FAT32 volumes, this field must be non-zero. For
FAT12/FAT16 volumes, this field contains the sector count if
BPB_TotSec16 is 0 (count is greater than or equal to 0x10000).
(This specifies that an unused BPB_TotSec32 field is set to zero.)
By the way fix offsets in include/grub/fat.h.
Tested with lDebug booted in qemu via grub2's
FreeDOS direct loading support, refer to
https://bitbucket.org/ecm/ldosboot + https://bitbucket.org/ecm/ldebug
Signed-off-by: C. Masloch <pushbx@38.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Starting from binutils commit bd7ab16b4537788ad53521c45469a1bdae84ad4a:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bd7ab16b4537788ad53521c45469a1bdae84ad4a
x86-64 assembler generates R_X86_64_PLT32, instead of R_X86_64_PC32, for
32-bit PC-relative branches. Grub2 should treat R_X86_64_PLT32 as
R_X86_64_PC32.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Code is currently ignoring errors from efibootmgr, giving users
clearly bogus output like:
Setting up grub-efi-amd64 (2.02~beta3-4) ...
Installing for x86_64-efi platform.
Could not delete variable: No space left on device
Could not prepare Boot variable: No space left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails, grub-install
should know that and report it!
We've been using similar patch in Debian now for some time, with no ill effects.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix the Open Firmware (OF) path property for sun4v SPARC systems.
These platforms do not have a /sas/ within their path. Over time
different OF addressing schemes have been supported. There
is no generic addressing scheme that works across every HBA.
It looks that this functionality will not work if you try to cross-install
SPARC GRUB2 binary using e.g. x86 grub-install. By default it should work.
However, we will also have other issues here, like lack of access to OF
firmware/paths, which make such configs unusable anyway. So, let's leave
this patch as is for time being. If somebody cares then he/she should fix
the issue(s) at some point.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add block-list GPT support for SPARC. The OBP "load" and "boot" methods
are partition aware and neither command can see the partition table. Also
neither command can address the entire physical disk. When the install
happens, grub generates the block-list entries based on the beginning of the
physical disk, not the beginning of the partition. This patch fixes the
block-list entries so they match what OBP expects during boot for a GPT disk.
T5 and above now supports GPT as well as VTOC.
This patch has been tested on T5-2 and newer SPARC systems.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Check the error bits in the interrupt status register. According to the
AHCI 1.2 spec, "Interrupt sources that are disabled (‘0’) are still
reflected in the status registers.", so this should work even though
grub uses polling
This fixes the following problem on a Fujitsu E744 laptop:
Sometimes there is a very long delay (up to several minutes) when
booting from hard disk. It seems accessing the DVD drive (which has no
disk inserted) sometimes fails with some errors, which leads to each
access being stalled until the 20s timeout triggers. This seems to
happen when grub is trying to read filesystem/partition data.
The problem is that the command_issue bit that is checked in the loop is
only reset if the "HBA receives a FIS which clears the BSY, DRQ, and ERR
bits for the command", but the ERR bit is never cleared. Therefore
command_issue is never reset and grub waits for the timeout.
The relevant bit in our case is the Task File Error Status (TFES), which
is equivalent to the ERR bit 0 in tfd. But this patch also checks
the other error bits except for the "Interface non-fatal error status"
bit.
Signed-off-by: Stefan Fritsch <fritsch@genua.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub-mkconfig will set GRUB_TERMINAL_OUTPUT to "gfxterm" unless the user
has overridden it. On EFI systems, this will stop output from going to the
default "console" terminal. When the EFI fw console is configured to output to
both serial and video, this will cause GRUB to only display on video - while
continuing to accept input from both video and serial.
Instead of switching from "console" to "gfxterm", let's output to both.
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The properties #address-cells and #size-cells are used to know the
number of cells for ranges provided by "regs". If they don't exist, the
value are resp. 2 and 1.
Currently, when multiboot nodes are created it is assumed that #address-cells
and #size-cells are exactly 2. However, they are never set by GRUB and
will result to later failure when the device-tree is generated by GRUB
or contain different values.
To prevent this failure, create the both properties in the chosen nodes.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub-mkconfig detects detached RSA signatures for kernel images used for
signature checking as valid images and adds them to grub.cfg as separate
menu entries. This patch adds .sig extension to common blacklist.
Signed-off-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Prevent a double open. This can cause problems with some ieee1275
devices, causing the system to hang. The double open can occur
as follows:
grub_ls_list_files (char *dirname, int longlist, int all, int human)
dev = grub_device_open (device_name);
dev remains open while:
grub_normal_print_device_info (device_name);
dev = grub_device_open (name);
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On efi systems, make pmtimer based tsc calibration the default over the
pit. This prevents Grub from hanging on Intel SoC systems that power gate
the pit.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When we exit grub, we don't free all the memory that we allocated earlier
for our heap region. This can cause problems with setups where you try
to descend the boot order using "exit" entries, such as PXE -> HD boot
scenarios.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The reboot function calls machine_fini() and then reboots the system.
Currently it lives in lib/ which means it gets compiled into the
reboot module which lives on the heap.
In a following patch, I want to free the heap on machine_fini()
though, so we would free the memory that the code is running in. That
obviously breaks with smarter UEFI implementations.
So this patch moves it into the core. That way we ensure that all
code running after machine_fini() in the UEFI case is running from
memory that got allocated (and gets deallocated) by the UEFI core.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The multiboot2 is much more preferable than multiboot. Especiall
if booting under EFI where multiboot does not have the functionality
to pass ImageHandler.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit d33045ce7f introduced
the support for this, but it does not work under x86 (as it stops
20_linux_xen from running).
The 20_linux_xen is run under a shell and any exits from within it:
(For example on x86):
+ /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
[root@tst063 grub]# echo $?
1
will result in 20_linux_xen exiting without continuing
and also causing grub2-mkconfig to stop processing.
As in:
[root@tst063 grub]# ./grub-mkconfig | tail
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.13.0-0.rc5.git1.1.fc27.x86_64
Found initrd image: /boot/initramfs-4.13.0-0.rc5.git1.1.fc27.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2
Found initrd image: /boot/initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
echo 'Loading Linux 0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 ...'
linux /vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 root=/dev/mapper/fedora_tst063-root ro single
echo 'Loading initial ramdisk ...'
initrd /initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
}
}
### END /usr/local/etc/grub.d/10_linux ###
### BEGIN /usr/local/etc/grub.d/20_linux_xen ###
root@tst063 grub]#
And no more.
This patch wraps the invocation of grub-file to be a in subshell
and to process the return value in a conditional. That fixes
the issue.
RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
CC: Fu Wei <fu.wei@linaro.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The `grub_util_exec_redirect_all` helper function can be used to
spawn an executable and redirect its output to some files. After calling
`fork()`, the parent will wait for the child to terminate with
`waitpid()` while the child prepares its file descriptors, environment
and finally calls `execvp()`. If something in the children's setup
fails, it will stop by calling `exit(127)`.
Calling `exit()` will cause any function registered via `atexit()` to be
executed, which is usually the wrong thing to do in a child. And
actually, one can easily observe faulty behaviour on musl-based systems
without modprobe(8) installed: executing `grub-install --help` will call
`grub_util_exec_redirect_all` with "modprobe", which obviously fails if
modprobe(8) is not installed. Due to the child now exiting and invoking
the `atexit()` handlers, it will clean up some data structures of the
parent and cause it to be deadlocked in the `waitpid()` syscall.
The issue can easily be fixed by calling `_exit(127)` instead, which is
especially designed to be called when the atexit-handlers should not be
executed.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Previously we had multiboot and multiboot2 declaring the same symbols.
This can potentially lead to aliasing and strange behaviours when e.g.
module instead of module2 is used with multiboot2.
Bug: #51137
