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>
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>
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>
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>
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>
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 `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
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.
Closes: 50420
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
In preparation for turning this into a common loader for 32-bit and 64-bit
platforms, ensure the code will compile cleanly for either.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Add a generic GRUB_PE32_MAGIC definition for the PE 'MZ' tag and delete
the existing one in arm64/linux.h.
Update arm64 Linux loader to use this new definition.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
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.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
grub_efi_allocate_pages Essentially does 2 unrelated things:
* Allocate at fixed address.
* Allocate at any address.
To switch between 2 different functions it uses address == 0 as magic
value which is wrong as 0 is a perfectly valid fixed adress to allocate at.
Expose a new function, grub_efi_allocate_pages_real(), making it possible
to specify allocation type and memory type as supported by the UEFI
AllocatePages boot service.
Make grub_efi_allocate_pages() a consumer of the new function,
maintaining its old functionality.
Also delete some left-around #if 1/#else blocks in the affected
functions.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Use same algorithm as in libblkid from util-linux v2.30.
1. Take first 16 bytes from UTF-8 encoded string of VolumeSetIdentifier
2. If all bytes are hexadecimal digits, convert to lowercase and use as UUID
3. If first 8 bytes are not all hexadecimal digits, convert those 8 bytes
to their hexadecimal representation, resulting in 16 bytes for UUID
4. Otherwise, compose UUID from two parts:
1. part: converted first 8 bytes (which are hexadecimal digits) to lowercase
2. part: encoded following 4 bytes to their hexadecimal representation (16 bytes)
So UUID would always have 16 hexadecimal digits in lowercase variant.
According to UDF specification, first 16 Unicode characters of
VolumeSetIdentifier should be unique value and first 8 should be
hexadecimal characters.
In most cases all 16 characters are hexadecimal, but e.g. MS Windows
format.exe set only first 8 as hexadecimal and remaining as fixed
(non-unique) which violates specification.
UDF dstring has stored length in the last byte of buffer. Therefore last
byte is not part of recorded characters. And empty string in dstring is
encoded as empty buffer, including first byte (compression id).
when protocols_per_handle returns error, we can't use the pointers we
passed to it, and that includes trusting num_protocols.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On such a filesystem, inodes may have EXT4_ENCRYPT_FLAG set.
For a regular file, this means its contents are encrypted; for a
directory, this means the filenames in its directory entries are
encrypted; and for a symlink, this means its target is encrypted. Since
GRUB cannot decrypt encrypted contents or filenames, just issue an error
if it would need to do so. This is sufficient to allow unencrypted boot
files to co-exist with encrypted files elsewhere on the filesystem.
(Note that encrypted regular files and symlinks will not normally be
encountered outside an encrypted directory; however, it's possible via
hard links, so they still need to be handled.)
Tested by booting from an ext4 /boot partition on which I had run
'tune2fs -O encrypt'. I also verified that the expected error messages
are printed when trying to access encrypted directories, files, and
symlinks from the GRUB command line. Also ran 'sudo ./grub-fs-tester
ext4_encrypt'; note that this requires e2fsprogs v1.43+ and Linux v4.1+.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Don't use devspec to determine the OBP path on SPARC hardware. Within all
versions of Linux on SPARC, the devspec returns one of three values:
"none", "vnet-port", or "vdisk". Unlike on PPC, none of these values
are useful in determining the OBP path.
Before this patch grub-ofpathname always returned the wrong value
for a virtual disk. For example:
% grub-ofpathname /dev/vdiskc2
vdisk/disk@2:b
After this patch it now returns the correct value:
% grub-ofpathname /dev/vdiskc2
/virtual-devices@100/channel-devices@200/disk@2:b
Orabug: 24459765
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds "--nounzip" option support in order to
be compatible with the module command of multiboot on other architecture,
by this way we can simplify grub-mkconfig support code.
This patch also allow us to use zip compressed module(like Linux kernel
for Dom0).
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Xen is currently crashing because of malformed compatible property for
the boot module. This is because the property string is not
null-terminated as requested by the ePAR spec.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Fu Wei <fu.wei@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The ihandle is left open with a cd-core image. This will cause a delay
booting grub from a virtual cdrom in a LDOM. It will also cause problems
as Linux boots, since it expects the ihandle to be closed during init.
Orabug: 25911275
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds support for virtual LAN (VLAN) tagging. VLAN tagging allows
multiple VLANs in a bridged network to share the same physical network link
but maintain isolation:
http://en.wikipedia.org/wiki/IEEE_802.1Q
* grub-core/net/ethernet.c: Add check, get, and set vlan tag id.
* grub-core/net/drivers/ieee1275/ofnet.c: Get vlan tag id from bootargs.
* grub-core/net/arp.c: Add check.
* grub-core/net/ip.c: Likewise.
* include/grub/net/arp.h: Add vlantag attribute.
* include/grub/net/ip.h: Likewise.
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>
(cherry picked from commit 842c390469)
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>
(cherry picked from commit 563b1da6e6)
'Event' struct will be not used any more, instead we use the
'TCG_PCR_EVENT', so this patch remove the older 'Event' data struct.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
The original code use deprecated 'Event' data structure with the wrong
member variable names, which result in the build error. This patch
fix it by using 'TCG_PCR_EVENT'.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
In util/getroot and efidisk slightly modify exitsing comment to mostly
retain it but still make GCC7 compliant with respect to fall through
annotation.
In grub-core/lib/xzembed/xz_dec_lzma2.c it adds same comments as
upstream.
In grub-core/tests/setjmp_tets.c declare functions as "noreturn" to
suppress GCC7 warning.
In grub-core/gnulib/regexec.c use new __attribute__, because existing
annotation is not recognized by GCC7 parser (which requires that comment
immediately precedes case statement).
Otherwise add FALLTHROUGH comment.
Closes: 50598
Fixed loading of ACPI tables on EFI (side effect was apparent memory
corruption ranging from unpredictable behavior to system reset).
Reported by Nando Eva <nando4eva@ymail.com>
iPXE adds Simple File System Protocol to loaded image handle, as side
effect it also adds Block IO protocol (according to comments, to work
around some bugs in EDK2). GRUB assumes that every device with Block IO
is disk and skips network initialization entirely. But iPXE Block IO
implementation is just a stub which always fails for every operation
so cannot be used. Attempt to detect and skip such devices.
We are using media ID which iPXE sets to "iPXE" and block IO size in
hope that no real device would announce 1B block ...
Closes: 50518
UEFI 2.6 9.3.6.4 File Path Media Device Path says that Path Name is
"A NULL-terminated Path string including directory and file names".
Strip final NULL from Path Name in each File Path node when constructing
full path. To be on safe side, strip all of them.
Fixes failure chainloading grub from grub, when loaded grub truncates
image path and does not find its grub.cfg.
https://bugzilla.opensuse.org/show_bug.cgi?id=1026344
This was triggered by commit ce95549cc54b5d6f494608a7c390dba3aab4fba7;
before it we built Path Name without trailing NULL, and apparently all
other bootloaders use single File Path node, thus not exposing this bug.
1. Do not assume block list and fragment are mutually exclusive. Squash
can pack file tail as fragment (unless -no-fragments is specified); so
check read offset and read either from block list or from fragments as
appropriate.
2. Support sparse files with zero blocks.
3. Fix fragment read - frag.offset is absolute fragment position,
not offset relative to ino.chunk.
Reported and tested by Carlo Caione <carlo@endlessm.com>
In case of GRUB we put remapper after domain pages and not at 0x0.
In this case we use max_addr to put remapper. Unfortunately we increment
max_addr as well in this case resulting in virt mapping mapping page
at old max_addr and trying to boot using new max_addr.
Closes 46014.
Unified Extensible Firmware Interface Specification, Version 2.6,
section 2.3.4, x64 Platforms, boot services, says among others:
The stack must be 16-byte aligned. So, do it. Otherwise OS may
boot only by chance as it happens right now.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
According to EABI only STT_FUNC has convention of lowest bit indicating
execution mode. R_THM_{JUMP,CALL}* relocations are assumed to be pointing
to thumb mode unless they use STT_FUNC.
If ascent is bigger than height - 2, then we draw over character box but then
to clear cursor we only draw over character box. So trim ascent if necessarry.
These entries have placeholder for device name and so are useless for our
purpose. grub failed with something like
grub-install: error: failed to get canonical path of `systemd-1'.
When we see autofs entry, record it (to keep parent-child relationship) but
continue to look for real mount. If it is found, we process it as usual. If
only autofs entry exists, attempt to trigger mount by opening mount point
and retry. Mount point itself is then kept open to avoid timeout.
Recent systemd is by default using automount for /boot/efi so this should
become more popular problem on EFI systems.
Closes: 49942
The path returned by grub_efi_net_config has already been stripped for the
directory part extracted from cached bootp packet. We should just return the
result to avoild it be stripped again.
It fixed the problem that grub.efi as NBP image always looking for grub.cfg and
platform directory in upper folder rather than current one it gets loaded while
$prefix is empty. The behavior is inconsistent with other architecture and how
we would expect empty $prefix going to be in general.
The only exception to the general rule of empty $prefix is that when loaded
from platform directory itself, the platform part is stripped thus upper folder
is used for looking up files. It meets the case for how grub-mknetdir lay out
the files under tftp root directory, but also hide away this issue to be
identified as it appears to be just works.
Also fix possible memory leak by moving grub_efi_get_filename() call after
grub_efi_net_config().
EFI File Path Media Device Path is defined as NULL terminated string;
but chainloader built file paths without final NULL. This caused error
with Secure Boot and Linux Foundation PreLoader on Acer with InsydeH20 BIOS.
Apparently firmware failed verification with EFI_INVALID_PARAMETER which is
considered fatal error by PreLoader.
Reported and tested by Giovanni Santini <itachi.sama.amaterasu@gmail.com>
get_card_packet() from ofnet.c allocates a netbuff based on the device's MTU:
nb = grub_netbuff_alloc (dev->mtu + 64 + 2);
In the case when the MTU is large, and the received packet is
relatively small, this leads to allocation of significantly more memory,
than it's required. An example could be transmission of TFTP packets
with 0x400 blksize via a network card with 0x10000 MTU.
This patch implements a per-card receive buffer in a way similar to efinet.c,
and makes get_card_packet() allocate a netbuff of the received data size.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the current code search_net_devices() uses the "alloc-mem" command
from the IEEE1275 User Interface for allocation of the transmit buffer
for the case when GRUB_IEEE1275_FLAG_VIRT_TO_REAL_BROKEN is set.
I don't have hardware where this flag is set to verify if this
workaround is still needed. However, further changes to ofnet will
require to execute this workaround one more time. Therefore, to
avoid possible duplication of code I'm moving this piece of
code into a function.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We only support FDT files with EFI on arm and arm64 systems, not
on x86. So move the helper that finds a prepopulated FDT UUID
into its own file and only build it for architectures where it
also gets called.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Network boot autoconfiguration sets default server to next server IP
(siaddr) from BOOTP/DHCP reply, but manual configuration using net_bootp
exports only server name. Unfortunately semantic of server name is not
clearly defined. BOOTP RFC 951 defines it only for client request, and
DHCP RFC 1541 only mentions it, without any implied usage. It looks like
this field is mostly empty in server replies.
Export next server IP as net_<interface>_next_server variable. This allows
grub configuration script to set $root/$prefix based on information obtained
by net_bootp.
Reported and tested by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: nikunj@linux.vnet.ibm.com
v2: change variable name to net_<interface>_next_server as discussed on the list
Searching for a device tree that EFI passes to us via configuration tables
is nothing architecture specific. Move it into generic code.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
grub_util_get_dm_abstraction() does a string comparison of insufficient
length. When using a UUID such as "CRYPT-PLAIN-sda6_crypt", the function
returns GRUB_DEV_ABSTRACTION_LUKS.
This results in the error:
./grub-probe: error: disk `cryptouuid/sda6_crypt' not found.
This appears to be a copy/paste error introduced in:
a10e7a5a89
The bug was (apparently) latent until revealed by:
3bca85b418
Signed-off-by: Corey Hickey <bugfood-c@fatooh.org>
Modern pvops linux kernels support a p2m list not covered by the
kernel mapping. This capability is flagged by an elf-note specifying
the virtual address the kernel is expecting the p2m list to be mapped
to.
In case the elf-note is set by the kernel don't place the p2m list
into the kernel mapping, but map it to the given address. This will
allow to support domains with larger memory, as the kernel mapping is
limited to 2GB and a domain with huge memory in the TB range will have
a p2m list larger than this.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Modify the page table construction to allow multiple virtual regions
to be mapped. This is done as preparation for removing the p2m list
from the initial kernel mapping in order to support huge pv domains.
This allows a cleaner approach for mapping the relocator page by
using this capability.
The interface to the assembler level of the relocator has to be changed
in order to be able to process multiple page table areas.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Modern pvops linux kernels support an initrd not covered by the initial
mapping. This capability is flagged by an elf-note.
In case the elf-note is set by the kernel don't place the initrd into
the initial mapping. This will allow to load larger initrds and/or
support domains with larger memory, as the initial mapping is limited
to 2GB and it is containing the p2m list.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Do the allocation of page tables in a separate function. This will
allow to do the allocation at different times of the boot preparations
depending on the features the kernel is supporting.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Do the allocation of special pages (start info, console and xenbus
ring buffers) in a separate function. This will allow to do the
allocation at different times of the boot preparations depending on
the features the kernel is supporting.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Do the p2m list allocation of the to be loaded kernel in a separate
function. This will allow doing the p2m list allocation at different
times of the boot preparations depending on the features the kernel
is supporting.
While at this remove superfluous setting of first_p2m_pfn and
nr_p2m_frames as those are needed only in case of the p2m list not
being mapped by the initial kernel mapping.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Various features and parameters of a pv-kernel are specified via
elf notes in the kernel image. Those notes are part of the interface
between the Xen hypervisor and the kernel.
Instead of using num,bers in the code when interpreting the elf notes
make use of the header supplied by Xen for that purpose.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The loader for xen paravirtualized environment is using lots of global
variables. Reduce the number by making them either local or by putting
them into a single state structure.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When loading a Xen pv-kernel avoid memory leaks in case of errors.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The loader for xen paravirtualized environment isn't callable multiple
times as it won't free any memory in case of failure.
Call grub_relocator_unload() as other modules do it before allocating
a new relocator or when unloading the module.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.
This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.
This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it should
be build. At least to build proper test/example files.
So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.
This patch was tested with Xen image which uses that functionality. However, this Xen
feature is still under development and new patchset will be released in about 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
limit_time underflows when current time is less than 90000ms.
This causes packet fragments received during this time, i.e.,
till 90000ms pass since timer init, to be rejected.
Hence, set it to 0 if its less than 90000.
Signed-off-by: Sakar Arora <Sakar.Arora@nxp.com>
