The upcoming support for LUKS2 disc encryption requires us to include a
parser for base64-encoded data, as it is used to represent salts and
digests. As gnulib already has code to decode such data, we can just
add it to the boostrapping configuration in order to make it available
in GRUB.
The gnulib module makes use of booleans via the <stdbool.h> header. As
GRUB does not provide any POSIX wrapper header for this, but instead
implements support for bool in <sys/types.h>, we need to patch
base64.h to not use <stdbool.h> anymore. We unfortunately cannot include
<sys/types.h> instead, as it would then use gnulib's internal header
while compiling the gnulib object but our own <sys/types.h> when
including it in a GRUB module. Because of this, the patch replaces the
include with a direct typedef.
A second fix is required to make available _GL_ATTRIBUTE_CONST, which
is provided by the configure script. As base64.h does not include
<config.h>, it is thus not available and results in a compile error.
This is fixed by adding an include of <config-util.h>.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
While the newly added jsmn library provides the parsing interface, it
does not provide any kind of interface to act on parsed tokens. Instead,
the caller is expected to handle pointer arithmetics inside of the token
array in order to extract required information. While simple, this
requires users to know some of the inner workings of the library and is
thus quite an unintuitive interface.
This commit adds a new interface on top of the jsmn parser that provides
convenience functions to retrieve values from the parsed json type, grub_json_t.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The upcoming support for LUKS2 encryption will require a JSON parser to
decode all parameters required for decryption of a drive. As there is
currently no other tool that requires JSON, and as gnulib does not
provide a parser, we need to introduce a new one into the code base. The
backend for the JSON implementation is going to be the jsmn library [1].
It has several benefits that make it a very good fit for inclusion in
GRUB:
- It is licensed under MIT.
- It is written in C89.
- It has no dependencies, not even libc.
- It is small with only about 500 lines of code.
- It doesn't do any dynamic memory allocation.
- It is testen on x86, amd64, ARM and AVR.
The library itself comes as a single header, only, that contains both
declarations and definitions. The exposed interface is kind of
simplistic, though, and does not provide any convenience features
whatsoever. Thus there will be a separate interface provided by GRUB
around this parser that is going to be implemented in the following
commit. This change only imports jsmn.h from tag v1.1.0 and adds it
unmodified to a new json module with the following command:
curl -L https://raw.githubusercontent.com/zserge/jsmn/v1.1.0/jsmn.h \
-o grub-core/lib/json/jsmn.h
Upstream jsmn commit hash: fdcef3ebf886fa210d14956d3c068a653e76a24e
Upstream jsmn commit name: Modernize (#149), 2019-04-20
[1]: https://github.com/zserge/jsmn
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In some cases GRUB2 allocates multiboot2 structure at 0 address, that is
a confusing behavior. Consumers of that structure can have internal NULL-checks
that will throw an error when get a pointer to data allocated at address 0.
To prevent that, define min address for mbi allocation on x86 and x86_64
platforms.
Signed-off-by: Lukasz Hawrylko <lukasz.hawrylko@linux.intel.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Recent work around x86 Linux kernel loader revealed an underflow in the
setup_header length calculation and another related issue. Both lead to
the memory overwrite and later machine crash.
Currently when the GRUB copies the setup_header into the linux_params
(struct boot_params, traditionally known as "zero page") it assumes the
setup_header size as sizeof(linux_i386_kernel_header/lh). This is
incorrect. It should use the value calculated accordingly to the Linux
kernel boot protocol. Otherwise in case of pretty old kernel, to be
exact Linux kernel boot protocol, the GRUB may write more into
linux_params than it was expected to. Fortunately this is not very big
issue. Though it has to be fixed. However, there is also an underflow
which is grave. It happens when
sizeof(linux_i386_kernel_header/lh) > "real size of the setup_header".
Then len value wraps around and grub_file_read() reads whole kernel into
the linux_params overwriting memory past it. This leads to the GRUB
memory allocator breakage and finally to its crash during boot.
The patch fixes both issues. Additionally, it moves the code not related to
grub_memset(linux_params)/grub_memcpy(linux_params)/grub_file_read(linux_params)
section outside of it to not confuse the reader.
Fixes: e683cfb0cf (loader/i386/linux: Calculate the setup_header length)
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
New 3- and 4-copy variants of RAID1 were merged into Linux kernel 5.5.
Add the two new profiles to the list of recognized ones. As this builds
on the same code as RAID1, only the redundancy level needs to be
adjusted, the rest is done by the existing code.
Signed-off-by: David Sterba <dsterba@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some TFTP servers do not handle multiple consecutive slashes correctly.
This patch avoids sending TFTP requests with non-normalized paths.
Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We are often bothered by this sort of lvm warning while running grub-install
every now and then:
File descriptor 4 (/dev/vda1) leaked on vgs invocation. Parent PID 1991: /usr/sbin/grub2-install
The requirement related to the warning is dictated in the lvm man page:
"On invocation, lvm requires that only the standard file descriptors stdin,
stdout and stderr are available. If others are found, they get closed and
messages are issued warning about the leak. This warning can be suppressed by
setting the environment variable LVM_SUPPRESS_FD_WARNINGS."
While it could be disabled through settings, most Linux distributions seem to
enable it by default and the justification provided by the developer looks to
be valid to me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15
Rather than trying to close and reopen the file descriptor to the same file
multiple times, which is rather cumbersome, for the sake of no vgs invocation
could happen in between. This patch enables the close-on-exec flag (O_CLOEXEC)
for new file descriptor returned by the open() system call, making it closed
thus not inherited by the child process forked and executed by the exec()
family of functions.
Fixes Debian bug #466138.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch fixes an issue that prevented the at_keyboard module to work
(for me). The cause was a bad/wrong return value in the
grub_at_keyboard_getkey() function in grub-core/term/at_keyboard.c file
at line 237. My symptoms were to have an unresponsive keyboard. Keys
needed to be pressed 10x and more to effectively be printed sometimes
generating multiple key presses (after 1 or 2 sec of no printing). It
was very problematic when typing passphrase in early stage (with
GRUB_ENABLE_CRYPTODISK). When switched to "console" terminal input
keyboard worked perfectly. It also worked great with the GRUB 2.02
packaged by Debian (2.02+dfsg1-20). It was not an output issue but an
input one.
I've managed to analyze the issue and found that it came from the commit
216950a4e (at_keyboard: Split protocol from controller code.). Three
lines where moved from the fetch_key() function in
grub-core/term/at_keyboard.c file to the beginning of
grub_at_keyboard_getkey() function (same file). However, returning -1
made sense when it happened in fetch_key() function but not anymore in
grub_at_keyboard_getkey() function which should return GRUB_TERM_NO_KEY.
I think it was just an incomplete cut-paste missing a small manual
correction. Let's fix it.
Note: Commit message updated by Daniel Kiper.
Signed-off-by: Michael Bideau <mica.devel@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Extend partition UUID probing support in GRUB core to display pseudo
partition UUIDs for MBR (MSDOS) partitions.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Don't free file->data on receiving FIN flag since it is used all over
without checking. http_close() will be called later to free that memory.
Fixes bug: https://bugzilla.redhat.com/show_bug.cgi?id=860834
Signed-off-by: Gustavo Luiz Duarte <gustavold@linux.vnet.ibm.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The device tree may passed by the firmware as UEFI configuration
table. Let lsefisystab display a short text and not only the GUID
for the device tree.
Here is an example output:
grub> lsefisystab
Address: 0xbff694d8
Signature: 5453595320494249 revision: 00020046
Vendor: Das U-Boot, Version=20190700
2 tables:
0xbe741000 eb9d2d31-2d88-11d3-9a160090273fc14d SMBIOS
0x87f00000 b1b621d5-f19c-41a5-830bd9152c69aae0 DEVICE TREE
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following are two use cases from Rajat Jain <rajatjain@juniper.net>:
1) We have a board that boots Linux and this board itself can be plugged
into one of different chassis types. We need to pass different
parameters to the kernel based on the "CHASSIS_TYPE" information
that is passed by the bios in the DMI/SMBIOS tables.
2) We may have a USB stick that can go into multiple boards, and the
exact kernel to be loaded depends on the machine information
(PRODUCT_NAME etc) passed via the DMI.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This adds the GUID and includes it in lsefisystab output.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Blocklist fallout cleanup after commit 5c6f9bc15 (generic/blocklist: Fix
implicit declaration of function grub_file_filter_disable_compression()).
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Linux supports root=PARTUUID=<partuuid> boot argument, so add
support for probing it. Compared to the fs UUID, the partition
UUID does not change when reformatting a partition.
For now, only disks using a GPT partition table are supported.
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Unlike in case of disks in this case it's just a single place, so it's easier
to just #undef
Signed-off-by: Vladimir Serbinenko <phcoder@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Disable the -Wadress-of-packaed-member diagnostic for the grub_f2fs_label
function since the result is found to be false postive.
A pointer to the 'volume_name' member of 'struct grub_f2fs_superblock' is
guaranteed to be aligned as the offset of 'volume_name' within the struct
is dividable by the natural alignment on both 32- and 64-bit targets.
grub-core/fs/f2fs.c: In function ‘grub_f2fs_label’:
grub-core/fs/f2fs.c:1253:60: error: taking address of packed member of ‘struct grub_f2fs_superblock’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
1253 | *label = (char *) grub_f2fs_utf16_to_utf8 (data->sblock.volume_name);
| ~~~~~~~~~~~~^~~~~~~~~~~~
cc1: all warnings being treated as errors
Reported-by: Neil MacLeod <neil@nmacleod.com>
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Tested-by: Neil MacLeod <neil@nmacleod.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On UEFI, 'text' gfxpayload is not supported, but we still reach parse_modespec()
with it, which will obviously fail. Fortunately, whatever gfxpayload is set,
we still still have the 'auto' default to fall back to. Allow getting to this
fallback by not trying to parse 'text' as a modespec.
This is because 'text' correctly doesn't parse as a modespec, and ought to have
been ignored before we got to that point, just like it is immediately picked if
we're running on a system where 'text' is a supported video mode.
Bug: https://savannah.gnu.org/bugs/index.php?56217
Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function grub_get_node_path() could return uninitialized offset with
level == 0 if the block is greater than direct_index + 2 * direct_blks +
2 * indirect_blks + dindirect_blks. The uninitialized offset is then used
by function grub_f2fs_get_block() because level == 0 is valid and
meaningful return to be processed.
The fix is to set level = -1 as return value by grub_get_node_path() to
signify an error that the input block cannot be handled. Any caller
should therefore check level is negative or not before processing the
output.
Reported-by: Neil MacLeod <neil@nmacleod.com>
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Neil MacLeod <neil@nmacleod.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The address of fp->path_name could be unaligned since seeking into the
device path buffer for a given node could end in byte boundary.
The fix is allocating aligned buffer by grub_malloc for holding the
UTF16 string copied from fp->path_name, and after using that buffer as
argument for grub_utf16_to_utf8 to convert it to UTF8 string.
[ 255s] ../../grub-core/kern/efi/efi.c: In function 'grub_efi_get_filename':
[ 255s] ../../grub-core/kern/efi/efi.c:410:60: error: taking address of packed member of 'struct grub_efi_file_path_device_path' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 255s] 410 | p = (char *) grub_utf16_to_utf8 ((unsigned char *) p, fp->path_name, len);
[ 255s] | ~~^~~~~~~~~~~
[ 255s] ../../grub-core/kern/efi/efi.c: In function 'grub_efi_print_device_path':
[ 255s] ../../grub-core/kern/efi/efi.c:900:33: error: taking address of packed member of 'struct grub_efi_file_path_device_path' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 255s] 900 | *grub_utf16_to_utf8 (buf, fp->path_name,
[ 255s] | ~~^~~~~~~~~~~
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The address of fp->path_name could be unaligned since seeking into the
device path buffer for a given node could end in byte boundary.
The fix is using aligned buffer allocated by grub_malloc for receiving
the converted UTF16 string by grub_utf8_to_utf16 and also the processing
after. The resulting string then gets copied to fp->path_name.
[ 243s] ../../grub-core/loader/efi/chainloader.c: In function 'copy_file_path':
[ 243s] ../../grub-core/loader/efi/chainloader.c:136:32: error: taking address of packed member of 'struct grub_efi_file_path_device_path' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 243s] 136 | size = grub_utf8_to_utf16 (fp->path_name, len * GRUB_MAX_UTF16_PER_UTF8,
[ 243s] | ~~^~~~~~~~~~~
[ 243s] ../../grub-core/loader/efi/chainloader.c:138:12: error: taking address of packed member of 'struct grub_efi_file_path_device_path' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 243s] 138 | for (p = fp->path_name; p < fp->path_name + size; p++)
[ 243s] | ^~
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Disable the -Wadress-of-packaed-member diagnostic for the
grub_usb_get_string function since the result is false postive. The
descstrp->str is found to be aligned in the buffer allocated for 'struct
grub_usb_desc_str'.
[ 229s] ../../grub-core/commands/usbtest.c: In function 'grub_usb_get_string':
[ 229s] ../../grub-core/commands/usbtest.c:104:58: error: taking address of packed member of 'struct grub_usb_desc_str' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 229s] 104 | *grub_utf16_to_utf8 ((grub_uint8_t *) *string, descstrp->str,
[ 229s] | ~~~~~~~~^~~~~
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The catkey->name could be unaligned since the address of 'void* record'
is calculated as offset in bytes to a malloc buffer.
The fix is using aligned buffer allocated by grub_malloc for holding
the UTF16 string copied from catkey->name. And use that buffer as
argument for grub_utf16_to_utf8 to convert to UTF8 strings.
In addition, using a new copy of buffer rather than catkey->name itself
for processing the endianess conversion, we can also get rid of the hunk
restoring byte order of catkey->name to what it was previously.
[ 59s] ../grub-core/fs/hfsplus.c: In function 'list_nodes':
[ 59s] ../grub-core/fs/hfsplus.c:738:57: error: taking address of packed member of 'struct grub_hfsplus_catkey' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 738 | *grub_utf16_to_utf8 ((grub_uint8_t *) filename, catkey->name,
[ 59s] | ~~~~~~^~~~~~
[ 59s] ../grub-core/fs/hfsplus.c: In function 'grub_hfsplus_label':
[ 59s] ../grub-core/fs/hfsplus.c:1019:57: error: taking address of packed member of 'struct grub_hfsplus_catkey' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 1019 | *grub_utf16_to_utf8 ((grub_uint8_t *) (*label), catkey->name,
[ 59s] | ~~~~~~^~~~~~
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Disable the -Wadress-of-packaed-member diagnostic for the
grub_jfs_getent function since the result is found to be false postive.
The leaf is read into memory as continous chunks in size of 32 bytes and
the pointer to its base is aligned, which also guarentee its member
leaf->namepart is aligned.
[ 60s] ../grub-core/fs/jfs.c: In function 'grub_jfs_getent':
[ 60s] ../grub-core/fs/jfs.c:557:44: error: taking address of packed member of 'struct grub_jfs_leaf_dirent' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 60s] 557 | le_to_cpu16_copy (filename + strpos, leaf->namepart, len < diro->data->namecomponentlen ? len
[ 60s] | ~~~~^~~~~~~~~~
[ 60s] ../grub-core/fs/jfs.c:570:48: error: taking address of packed member of 'struct grub_jfs_leaf_next_dirent' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 60s] 570 | le_to_cpu16_copy (filename + strpos, next_leaf->namepart, len < 15 ? len : 15);
[ 60s] | ~~~~~~~~~^~~~~~~~~~
[ 60s] cc1: all warnings being treated as errors
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Disable the -Wadress-of-packaed-member diagnostic for the
grub_cpio_find_file function since the result is found to be false
postive. Any pointers to member of the 'struct head hd' is aligned even
if the structure is packed without paddings.
[ 59s] In file included from ../grub-core/fs/cpio.c:51:
[ 59s] ../grub-core/fs/cpio_common.c: In function 'grub_cpio_find_file':
[ 59s] ../grub-core/fs/cpio_common.c:58:31: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 58 | data->size = read_number (hd.filesize, ARRAY_SIZE (hd.filesize));
[ 59s] | ~~^~~~~~~~~
[ 59s] ../grub-core/fs/cpio_common.c:60:29: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 60 | *mtime = read_number (hd.mtime, ARRAY_SIZE (hd.mtime));
[ 59s] | ~~^~~~~~
[ 59s] ../grub-core/fs/cpio_common.c:61:28: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 61 | modeval = read_number (hd.mode, ARRAY_SIZE (hd.mode));
[ 59s] | ~~^~~~~
[ 59s] ../grub-core/fs/cpio_common.c:62:29: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 62 | namesize = read_number (hd.namesize, ARRAY_SIZE (hd.namesize));
[ 59s] | ~~^~~~~~~~~
[ 59s] In file included from ../grub-core/fs/cpio_be.c:51:
[ 59s] ../grub-core/fs/cpio_common.c: In function 'grub_cpio_find_file':
[ 59s] ../grub-core/fs/cpio_common.c:58:31: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 58 | data->size = read_number (hd.filesize, ARRAY_SIZE (hd.filesize));
[ 59s] | ~~^~~~~~~~~
[ 59s] ../grub-core/fs/cpio_common.c:60:29: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 60 | *mtime = read_number (hd.mtime, ARRAY_SIZE (hd.mtime));
[ 59s] | ~~^~~~~~
[ 59s] ../grub-core/fs/cpio_common.c:61:28: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 61 | modeval = read_number (hd.mode, ARRAY_SIZE (hd.mode));
[ 59s] | ~~^~~~~
[ 59s] ../grub-core/fs/cpio_common.c:62:29: error: taking address of packed member of 'struct head' may result in an unaligned pointer value [-Werror=address-of-packed-member]
[ 59s] 62 | namesize = read_number (hd.namesize, ARRAY_SIZE (hd.namesize));
[ 59s] | ~~^~~~~~~~~
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The UEFI specification allows LoadImage() to be called with a memory
location only and without a device path. In this case FilePath will not be
set in the EFI_LOADED_IMAGE_PROTOCOL.
So in function grub_efi_get_filename() the device path argument may be
NULL. As we cannot determine the device path in this case just return NULL
from the function.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Function grub_strndup() may return NULL, this is called from
function grub_ieee1275_get_devname() which is then called from
function grub_ieee1275_encode_devname() to set device. The device
variable could then be used with a NULL pointer.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously the setup_header length was just assumed to be the size of the
linux_kernel_params struct. The linux x86 32-bit boot protocol says that the
end of the linux_i386_kernel_header is at 0x202 + the byte value at 0x201 in
the linux_i386_kernel_header. So, calculate the size of the header using the
end of the linux_i386_kernel_header, rather than assume it is the size of the
linux_kernel_params struct.
Additionally, add some required members to the linux_kernel_params
struct and align the content of linux_i386_kernel_header struct with
it. New members naming was taken directly from Linux kernel source.
linux_kernel_params and linux_i386_kernel_header structs require more
cleanup. However, this is not urgent, so, let's do this after release.
Just in case...
Signed-off-by: Andrew Jeddeloh <andrew.jeddeloh@coreos.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@google.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
Function grub_efi_find_last_device_path() may return NULL when called
from grub_efidisk_get_device_name().
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Function grub_efi_find_last_device() path may return NULL when called
from is_child().
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Function grub_efi_find_last_device_path() may return constant NULL when
called from find_parent_device().
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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 on external tools to do that.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch is similiar to commit e795b9011 (RISC-V: Add libgcc helpers
for clz) but for SPARC target.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
This patch is similiar to commit e795b9011 (RISC-V: Add libgcc helpers
for clz) but for MIPS target.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
MIPS fallout cleanup after commit 4d4a8c96e (verifiers: Add possibility
to verify kernel and modules command lines).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
PowerPC fallout cleanup after commit 4d4a8c96e (verifiers: Add possibility
to verify kernel and modules command lines) and ca0a4f689 (verifiers: File
type for fine-grained signature-verification controlling).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
IA-64 fallout cleanup after commit 4d4a8c96e (verifiers: Add possibility
to verify kernel and modules command lines).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
In addition to what was already there, Gnulib's <intprops.h> needs SCHAR_MIN,
SCHAR_MAX, SHRT_MIN, INT_MIN, LONG_MIN, and LONG_MAX. Fixes build on CentOS 7.
Reported-by: "Chen, Farrah" <farrah.chen@intel.com>
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mirror behaviour of ELF loader in libxc: first look for Xen notes in
PT_NOTE segment, then in SHT_NOTE section and only then fallback to
a section with __xen_guest name. This fixes loading PV kernels that
Xen note have outside of PT_NOTE. While this may be result of a buggy
linker script, loading such kernel directly works fine, so make it work
with GRUB too. Specifically, this applies to binaries built from Unikraft.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Various GRUB utilities fail if the current directory doesn't exist,
because grub_find_device() chdirs to a different directory and then
fails when trying to chdir back. Gnulib's save-cwd module uses fchdir()
instead when it can, avoiding this category of problem.
Fixes Debian bug #918700.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mostly for cosmetic reasons, we add a "net_dhcp" command, which is (at the
moment) identical to the existing "net_bootp" command. Both actually trigger
a DHCP handshake now, and both should be able to deal with pure BOOTP servers.
We could think about dropping the DHCP options from the initial DISCOVER packet
when the user issues the net_bootp command, but it's unclear whether this is
really useful, as both protocols should be able to coexist.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Even though we were parsing some DHCP options sent by the server, so far
we are only using the BOOTP 2-way handshake, even when talking to a DHCP
server.
Change this by actually sending out DHCP DISCOVER packets instead of the
generic (mostly empty) BOOTP BOOTREQUEST packets.
A pure BOOTP server would ignore the extra DHCP options in the DISCOVER
packet and would just reply with a BOOTREPLY packet, which we also
handle in the code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
