We bumped into the build error while testing gcc-10 pre-release.
In file included from ../../include/grub/file.h:22,
from ../../grub-core/fs/zfs/zfs.c:34:
../../grub-core/fs/zfs/zfs.c: In function 'zap_leaf_lookup':
../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '<unknown>' is outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=zero-length-bounds]
2263 | for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
../../include/grub/types.h:241:48: note: in definition of macro 'grub_le_to_cpu16'
241 | # define grub_le_to_cpu16(x) ((grub_uint16_t) (x))
| ^
../../grub-core/fs/zfs/zfs.c:2263:16: note: in expansion of macro 'grub_zfs_to_cpu16'
2263 | for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
| ^~~~~~~~~~~~~~~~~
In file included from ../../grub-core/fs/zfs/zfs.c:48:
../../include/grub/zfs/zap_leaf.h:72:16: note: while referencing 'l_hash'
72 | grub_uint16_t l_hash[0];
| ^~~~~~
Here I'd like to quote from the gcc document [1] which seems best to
explain what is going on here.
"Although the size of a zero-length array is zero, an array member of
this kind may increase the size of the enclosing type as a result of
tail padding. The offset of a zero-length array member from the
beginning of the enclosing structure is the same as the offset of an
array with one or more elements of the same type. The alignment of a
zero-length array is the same as the alignment of its elements.
Declaring zero-length arrays in other contexts, including as interior
members of structure objects or as non-member objects, is discouraged.
Accessing elements of zero-length arrays declared in such contexts is
undefined and may be diagnosed."
The l_hash[0] is apparnetly an interior member to the enclosed structure
while l_entries[0] is the trailing member. And the offending code tries
to access members in l_hash[0] array that triggers the diagnose.
Given that the l_entries[0] is used to get proper alignment to access
leaf chunks, we can accomplish the same thing through the ALIGN_UP macro
thus eliminating l_entries[0] from the structure. In this way we can
pacify the warning as l_hash[0] now becomes the last member to the
enclosed structure.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Last-update: 2020-12-28
Patch-Name: zfs-gcc-10.patch
We bumped into the build error while testing gcc-10 pre-release.
../../grub-core/disk/mdraid1x_linux.c: In function 'grub_mdraid_detect':
../../grub-core/disk/mdraid1x_linux.c:181:15: error: array subscript <unknown> is outside array bounds of 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=array-bounds]
181 | (char *) &sb.dev_roles[grub_le_to_cpu32 (sb.dev_number)]
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../grub-core/disk/mdraid1x_linux.c:98:17: note: while referencing 'dev_roles'
98 | grub_uint16_t dev_roles[0]; /* Role in array, or 0xffff for a spare, or 0xfffe for faulty. */
| ^~~~~~~~~
../../grub-core/disk/mdraid1x_linux.c:127:33: note: defined here 'sb'
127 | struct grub_raid_super_1x sb;
| ^~
cc1: all warnings being treated as errors
Apparently gcc issues the warning when trying to access sb.dev_roles
array's member, since it is a zero length array as the last element of
struct grub_raid_super_1x that is allocated sparsely without extra
chunks for the trailing bits, so the warning looks legitimate in this
regard.
As the whole thing here is doing offset computation, it is undue to use
syntax that would imply array member access then take address from it
later. Instead we could accomplish the same thing through basic array
pointer arithmetic to pacify the warning.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Last-Update: 2020-12-28
Patch-Name: mdraid1x-linux-gcc-10.patch
Commit 781b3e5efc (tftp: Do not use priority queue) caused a regression
when fetching files over TFTP whose size is bigger than 65535 * block size.
grub> linux /images/pxeboot/vmlinuz
grub> echo $?
0
grub> initrd /images/pxeboot/initrd.img
error: timeout reading '/images/pxeboot/initrd.img'.
grub> echo $?
28
It is caused by the block number counter being a 16-bit field, which leads
to a maximum file size of ((1 << 16) - 1) * block size. Because GRUB sets
the block size to 1024 octets (by using the TFTP Blocksize Option from RFC
2348 [0]), the maximum file size that can be transferred is 67107840 bytes.
The TFTP PROTOCOL (REVISION 2) RFC 1350 [1] does not mention what a client
should do when a file size is bigger than the maximum, but most TFTP hosts
support the block number counter to be rolled over. That is, acking a data
packet with a block number of 0 is taken as if the 65356th block was acked.
It was working before because the block counter roll-over was happening due
an overflow. But that got fixed by the mentioned commit, which led to the
regression when attempting to fetch files larger than the maximum size.
To allow TFTP file transfers of unlimited size again, re-introduce a block
counter roll-over so the data packets are acked preventing the timeouts.
[0]: https://tools.ietf.org/html/rfc2348
[1]: https://tools.ietf.org/html/rfc1350
Fixes: 781b3e5efc (tftp: Do not use priority queue)
Suggested-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1892290
Last-Update: 2020-11-08
Patch-Name: tftp-roll-over-block-counter.patch
Refactor clean_grub_dir() to create a backup of all the files, instead
of just irrevocably removing them as the first action. If available,
register atexit() handler to restore the backup if errors occur before
point of no return, or remove the backup if everything was successful.
If atexit() is not available, the backup remains on disk for manual
recovery.
Some platforms defined a point of no return, i.e. after modules & core
images were updated. Failures from any commands after that stage are
ignored, and backup is cleaned up. For example, on EFI platforms update
is not reverted when efibootmgr fails.
Extra care is taken to ensure atexit() handler is only invoked by the
parent process and not any children forks. Some older GRUB codebases
can invoke parent atexit() hooks from forks, which can mess up the
backup.
This allows safer upgrades of MBR & modules, such that
modules/images/fonts/translations are consistent with MBR in case of
errors. For example accidental grub-install /dev/non-existent-disk
currently clobbers and upgrades modules in /boot/grub, despite not
actually updating any MBR.
This patch only handles backup and restore of files copied to /boot/grub.
This patch does not perform backup (or restoration) of MBR itself or
blocklists. Thus when installing i386-pc platform, corruption may still
occur with MBR and blocklists which will not be attempted to be
automatically recovered.
Also add modinfo.sh and *.efi to the cleanup/backup/restore code path,
to ensure it is also cleaned, backed up and restored.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Last-Update: 2021-06-14
Patch-Name: grub-install-backup-and-restore.patch
The functions grub_util_exec_pipe() and grub_util_exec_pipe_stderr()
currently call execvp(). If the call fails for any reason, the child
currently calls exit(127). This in turn executes the parents
atexit() handlers from the forked child, and then the same handlers
are called again from parent. This is usually not desired, and can
lead to deadlocks, and undesired behavior. So, change the exit() calls
to _exit() calls to avoid calling atexit() handlers from child.
Fixes: e75cf4a58 (unix exec: avoid atexit handlers when child exits)
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Bug-Debian: https://bugs.debian.org/983435
Last-Update: 2021-06-14
Patch-Name: osdep-exec-avoid-atexit-when-child-exits.patch
The SECURITY file describes the GRUB project security policy.
It is based on https://github.com/wireapp/wire/blob/master/SECURITY.md
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>
Signed-off-by: Vladimir Serbinenko <phcoder@google.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
The MAINTAINERS file provides basic information about the GRUB project
and its maintainers.
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>
Signed-off-by: Vladimir Serbinenko <phcoder@google.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Refactor clean_grub_dir() to create a backup of all the files, instead
of just irrevocably removing them as the first action. If available,
register atexit() handler to restore the backup if errors occur before
point of no return, or remove the backup if everything was successful.
If atexit() is not available, the backup remains on disk for manual
recovery.
Some platforms defined a point of no return, i.e. after modules & core
images were updated. Failures from any commands after that stage are
ignored, and backup is cleaned up. For example, on EFI platforms update
is not reverted when efibootmgr fails.
Extra care is taken to ensure atexit() handler is only invoked by the
parent process and not any children forks. Some older GRUB codebases
can invoke parent atexit() hooks from forks, which can mess up the
backup.
This allows safer upgrades of MBR & modules, such that
modules/images/fonts/translations are consistent with MBR in case of
errors. For example accidental grub-install /dev/non-existent-disk
currently clobbers and upgrades modules in /boot/grub, despite not
actually updating any MBR.
This patch only handles backup and restore of files copied to /boot/grub.
This patch does not perform backup (or restoration) of MBR itself or
blocklists. Thus when installing i386-pc platform, corruption may still
occur with MBR and blocklists which will not be attempted to be
automatically recovered.
Also add modinfo.sh and *.efi to the cleanup/backup/restore code path,
to ensure it is also cleaned, backed up and restored.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The functions grub_util_exec_pipe() and grub_util_exec_pipe_stderr()
currently call execvp(). If the call fails for any reason, the child
currently calls exit(127). This in turn executes the parents
atexit() handlers from the forked child, and then the same handlers
are called again from parent. This is usually not desired, and can
lead to deadlocks, and undesired behavior. So, change the exit() calls
to _exit() calls to avoid calling atexit() handlers from child.
Fixes: e75cf4a58 (unix exec: avoid atexit handlers when child exits)
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux of
grub-core/lib/i386/relocator64.S
This file has six sections that only build with a 64-bit assembler,
yet only the first two sections had support for a 32-bit assembler.
This patch completes this for the remaining sections.
To reproduce, update the GRUB source description in your local Guix
archive and run
./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub
or install an x86 cross-build environment on x86-linux (32-bit!) and
configure to cross build and make, e.g., do something like
./configure \
CC_FOR_BUILD=gcc \
--build=i686-unknown-linux-gnu \
--host=i586-pc-gnu
make
Additionally, remove a line with redundant spaces.
Signed-off-by: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The XFS now has an incompat feature flag to indicate that a filesystem
needs to be repaired. The Linux kernel refuses to mount the filesystem
that has it set and only the xfs_repair tool is able to clear that flag.
The GRUB doesn't have the concept of mounting filesystems and just
attempts to read the files. But it does some sanity checking before
attempting to read from the filesystem. Among the things which are tested,
is if the super block only has set of incompatible features flags that
are supported by GRUB. If it contains any flags that are not listed as
supported, reading the XFS filesystem fails.
Since the GRUB doesn't attempt to detect if the filesystem is inconsistent
nor replays the journal, the filesystem access is a best effort. For this
reason, ignore if the filesystem needs to be repaired and just print a debug
message. That way, if reading or booting fails later, the user is able to
figure out that the failures can be related to broken XFS filesystem.
Suggested-by: Eric Sandeen <esandeen@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The XFS filesystem supports a bigtime feature to overcome y2038 problem.
This patch makes the GRUB able to support the XFS filesystems with this
feature enabled.
The XFS counter for the bigtime enabled timestamps starts at 0, which
translates to GRUB_INT32_MIN (Dec 31 20:45:52 UTC 1901) in the legacy
timestamps. The conversion to Unix timestamps is made before passing the
value to other GRUB functions.
For this to work properly, GRUB requires an access to flags2 field in the
XFS ondisk inode. So, the grub_xfs_inode structure has been updated to
cover full ondisk inode.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some filesystems nowadays use 64-bit types for timestamps. So, update
grub_dirhook_info struct to use an grub_int64_t type to store mtime.
This also updates the grub_unixtime2datetime() function to receive
a 64-bit timestamp argument and do 64-bit-safe divisions.
All the remaining conversion from 32-bit to 64-bit should be safe, as
32-bit to 64-bit attributions will be implicitly casted. The most
critical part in the 32-bit to 64-bit conversion is in the function
grub_unixtime2datetime() where it needs to deal with the 64-bit type.
So, for that, the grub_divmod64() helper has been used.
These changes enables the GRUB to support dates beyond y2038.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are already PRI*_T constants defined for unsigned integers but not
for signed integers. Add format specifiers for the latter.
Suggested-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The efi_shim_lock_guid local variable and shim_lock_guid global variable
have the same GUID value. Only the latter is retained.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit f60ba9e594 (util/mkimage: Refactor section setup to use a helper)
added a helper function to setup PE sections. But it also changed how the
raw data offsets were calculated since all the section sizes are aligned.
However, for some platforms, i.e ia64-efi and arm64-efi, the kernel image
size is not aligned using the section alignment. This leads to the situation
in which the mods section offset in its PE section header does not match its
real placement in the PE file. So, finally the GRUB is not able to locate
and load built-in modules.
The problem surfaces on ia64-efi and arm64-efi because both platforms
require additional relocation data which is added behind .bss section.
So, we have to add some padding behind this extra data to make the
beginning of mods section properly aligned in the PE file. Fix it by
aligning the kernel_size to the section alignment. That makes the sizes
and offsets in the PE section headers to match relevant sections in the
PE32+ binary file.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Additionally, fix the terminfo spelling mistake in
the GRUB development documentation.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
This is an additional fix which has been missing from the commit 837fe48de
(i18n: Format large integers before the translation message).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Commit f60ba9e594 (util/mkimage: Refactor section setup to use a helper)
added a helper function to setup PE sections, but it caused regressions
in some arches where the natural alignment lead to wrong section sizes.
This patch fixes a few things that were caused the section sizes to be
calculated wrongly. These fixes are:
* Only align the virtual memory addresses but not the raw data offsets.
* Use aligned sizes for virtual memory sizes but not for raw data sizes.
* Always align the sizes to set the virtual memory sizes.
These seems to not cause problems for x64 and aa64 EFI platforms but was
a problem for ia64. Because the size of the ".data" and "mods" sections
were wrong and didn't have the correct content. Which lead to GRUB not
being able to load any built-in module.
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Bug-Debian: https://bugs.debian.org/987103
Patch-Name: mkimage-fix-section-sizes.patch
The GNU gettext only supports the ISO C99 macros for integral
types. If there is a need to use unsupported formatting macros,
e.g. PRIuGRUB_UINT64_T, according to [1] the number to a string
conversion should be separated from the code printing message
requiring the internationalization. So, the function grub_snprintf()
is used to print the numeric values to an intermediate buffer and
the internationalized message contains a string format directive.
[1] https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#No-string-concatenation
Signed-off-by: Miguel Ángel Arruga Vivas <rosen644835@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since commit 7ce3259f67 (video/fb/fbfill: Fix potential integer
overflow), clang builds of grub-emu have failed with messages like:
/usr/bin/ld: libgrubmods.a(libgrubmods_a-fbfill.o): in function `grub_video_fbfill_direct24':
fbfill.c:(.text+0x28e): undefined reference to `__muloti4'
This appears to be due to a weird quirk in how clang compiles
grub_mul(dst->mode_info->bytes_per_pixel, width, &rowskip)
which is grub_mul(unsigned int, int, &grub_size_t).
It looks like clang somewhere promotes everything to 128-bit maths
before ultimately reducing down to 64 bit for grub_size_t. I think
this is because width is signed, and indeed converting width to an
unsigned int makes the problem go away.
This conversion also makes more sense generally:
- the caller of all the fbfill_directN functions is
grub_video_fb_fill_dispatch() and it takes width and height as
unsigned ints already,
- it doesn't make sense to fill a negative width or height.
Convert the width and height arguments and associated loop counters
to unsigned ints.
Fixes: 7ce3259f67 (video/fb/fbfill: Fix potential integer overflow)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since the possessive form of "it" is being used, the apostrophe must be omitted.
Signed-off-by: Aru Sahni <aru@arusahni.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The messages associated with other similar GRUB_ERR_OUT_OF_RANGE errors
were lacking the trailing full stop. Syncing up the strings saves a small
amount of precious core image space on i386-pc.
DOWN: obj/i386-pc/grub-core/kernel.img (31740 > 31708) - change: -32
DOWN: i386-pc core image (biosdisk ext2 part_msdos) (27453 > 27452) - change: -1
DOWN: i386-pc core image (biosdisk ext2 part_msdos diskfilter mdraid09) (32367 > 32359) - change: -8
Signed-off-by: Colin Watson <cjwatson@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The ext2 (and ext3, ext4) filesystems write the number of free inodes to
location 0x410.
On a MINIX filesystem, that same location is used for the MINIX superblock
magic number.
If the number of free inodes on an ext2 filesystem is equal to any
of the four MINIX superblock magic values plus any multiple of 65536,
GRUB's MINIX filesystem code will probe it as a MINIX filesystem.
In the case of an OS using ext2 as the root filesystem, since there will
ordinarily be some amount of file creation and deletion on every bootup,
it effectively means that this situation has a 1:16384 chance of being hit
on every reboot.
This will cause GRUB's filesystem probing code to mistakenly identify an
ext2 filesystem as MINIX. This can be seen by e.g. "search --label"
incorrectly indicating that no such ext2 partition with matching label
exists, whereas in fact it does.
After spotting the rough cause of the issue I was facing here, I borrowed
much of the diagnosis/explanation from meierfra who found and investigated
the same issue in util-linux in 2010:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/518582
This was fixed in util-linux by having the MINIX code check for the
ext2 magic. Do the same here.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Derek Foreman <derek@endlessos.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Given no core functions on i386-pc would require verifiers to work and
the only consumer of the verifier API is the pgp module, it looks good
to me that we can move the verifiers out of the kernel image and let
moddep.lst to auto-load it when pgp is loaded on i386-pc platform.
This helps to reduce the size of core image and thus can relax the
tension of exploding on some i386-pc system with very short MBR gap
size. See also a very comprehensive summary from Colin [1] about the
details.
[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00240.html
V2:
Drop COND_NOT_i386_pc and use !COND_i386_pc.
Add comment in kern/verifiers.c to help understanding what's going on
without digging into the commit history.
Reported-by: Colin Watson <cjwatson@debian.org>
Reviewed-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Michael Chang <mchang@suse.com>
Origin: other, https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00251.html
Bug-Debian: https://bugs.debian.org/984488
Bug-Debian: https://bugs.debian.org/985374
Last-Update: 2021-03-18
Patch-Name: pc-verifiers-module.patch
The hdr_offset member of the ARM Linux image header appears at
offset 0x3c, matching the PE/COFF spec's placement of the COFF
header offset in the MS-DOS header. We're currently off by four,
so fix that.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This should help prevent format string errors and thus improve the quality
of error reporting.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is a temporary, less-intrusive change to get the build to success with
compiler format string checking turned on. There is a better fix which
addresses this issue, but it needs more testing. Use this change so that
format string checking on grub_error() can be turned on until the better
change is fully tested.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The macro ELF_R_TYPE does not change the underlying type. Here its argument
is a 64-bit Elf64_Xword. Make sure the format code matches.
For the RISC-V architecture, rel->r_info could be either Elf32_Xword or
Elf64_Xword depending on if 32 or 64-bit RISC-V is being built. So cast
to 64-bit value regardless.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Also remove casting of format string args so that the architecture dependent
type is preserved.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
