A test exiting with code 99 means that there was an error in the test itself
and not a failure in the thing being tested (also known as a hard error).
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When a test program fails because it failed to setup the test properly, this
does not indicate a failure in what is attempting to be tested because the
test is never run. So exit with a hard error exit status to note this
difference. This will allow easier detection of tests that are not actually
being run and those that are really failing.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The script grub-shell does the bulk of the testing. If it returns an error
code, that means that the test failed and the test should immediately exit
with that error code. When grub-shell is used as a non-terminating command
in a pipeline, e.g. when data needs to be extracted from its output, its
error code will be occluded by the last command in the pipeline. Refactor
tests so that the shell will error with the exit code of grub-shell by
breaking up pipelines such that grub-shell is always the last command in
the pipeline that it is used in.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using the output of a subshell as input, its error code is ignored in
the context of "set -e". Many test scripts use grub-shell in a subshell with
output used as an argument to the test command to test for expected output.
Refactor these tests so that the subshell output goes to a shell variable,
so that if the subshell errors the script will immediately exit with an
error code.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This helps to ensure that error codes do not get ignored.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently, the filesystem timestamp check in grub-fs-tester uses the
squashfs image file's last modified timestamp and checks to see if that
time stamp is within 3 seconds of the superblock timestamp as determined by
grub. The image file's timestamp could be more than 3 seconds off if
mksquashfs takes more than 3 seconds to generate the image, as is the case
on a virtual machine. Instead use squashfs tools to get the filesystem
timestamp directly.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Perhaps using a newer UEFI firmware is the reason for the created test disk
showing up as hd2 instead of hd3.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following procedure to build xen/pvgrub is broken.
git clone https://git.savannah.gnu.org/git/grub.git
cd grub
./bootstrap
mkdir build-xen
cd build-xen
../configure --with-platform=xen
make
It fails with the message:
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
section .note.gnu.property VMA [0000000000400158,0000000000400187]
overlaps section .bss VMA [000000000000f000,000000000041e1af]
The most significant factor is that new assembler (GNU as) generates the
.note.gnu.property section as default. This note section overlaps with
.bss because it doesn't reposition with -Wl,-Ttext,0 with which the base
address of .text section is set, rather the address of .note.gnu.property
is calculated for some reason from 0x400000 where the ELF executable
defaults to start.
Using -Ttext-segment doesn't help either, though it is said to set the
address of the first byte of the text segment according to "man ld".
What it actually does is to override the default 0x400000, aka the image
base address, to something else. The entire process can be observed in
the default linker script used by gcc [1]. Therefore we can't expect it
to achieve the same thing as -Ttext given that the first segment where
.text resides is offset by SIZEOF_HEADERS plus some sections may be
preceding it within the first segment. The end result is .text always
has to start with non-zero address with -Wl,-Ttext-segment,0 if using
default linker script.
It is also worth mentioning that binutils upstream apparently doesn't
seem to consider this as a bug [2] and proposed to use -Wl,-Ttext-segment,0
which is not fruitful as what has been tested by Gentoo [3].
As long as GRUB didn't use ISA information encoded in .note.gnu.property,
we can safely drop it via -Wa,-mx86-used-note=no assembler option to
fix the linker error above.
This is considered a better approach than using custom linker script to
drop the .note.gnu.property section because object file manipulation can
also be hampered one way or the other in that linker script may not be
helpful. See also this commit removing the section in the process of objcopy.
6643507ce build: Fix GRUB i386-pc build with Ubuntu gcc
[1] In /usr/lib64/ldscripts/elf_x86_64.x or use 'gcc -Wl,--verbose ...'
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=27377
[3] https://bugs.gentoo.org/787221
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently the grub_diskfilter_memberlist() function returns all physical
volumes added to a volume group to which a logical volume (LV) belongs.
However, this is suboptimal as it doesn't fit the intended behavior of
returning underlying devices that make up the LV. To give a clear
picture, the result should be identical to running commands below to
display the logical volumes with underlying physical volumes in use.
localhost:~ # lvs -o lv_name,vg_name,devices /dev/system/root
LV VG Devices
root system /dev/vda2(512)
localhost:~ # lvdisplay --maps /dev/system/root
--- Logical volume ---
...
--- Segments ---
Logical extents 0 to 4604:
Type linear
Physical volume /dev/vda2
Physical extents 512 to 5116
As shown above, we can know system-root LV uses only /dev/vda2 to
allocate it's extents, or we can say that /dev/vda2 is the member device
comprising the system-root LV.
It is important to be precise on the member devices, because that helps
to avoid pulling in excessive dependency. Let's use an example to
demonstrate why it is needed.
localhost:~ # findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/system-root ext4 rw,relatime
localhost:~ # pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/data system lvm2 a-- 1020.00m 0
/dev/vda2 system lvm2 a-- 19.99g 0
localhost:~ # cryptsetup status /dev/mapper/data
/dev/mapper/data is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/vdb
sector size: 512
offset: 4096 sectors
size: 2093056 sectors
mode: read/write
localhost:~ # vgs
VG #PV #LV #SN Attr VSize VFree
system 2 3 0 wz--n- 20.98g 0
localhost:~ # lvs -o lv_name,vg_name,devices
LV VG Devices
data system /dev/mapper/data(0)
root system /dev/vda2(512)
swap system /dev/vda2(0)
We can learn from above that /dev/mapper/data is an encrypted volume and
also gets assigned to volume group "system" as one of it's physical
volumes. And also it is not used by root device, /dev/mapper/system-root,
for allocating extents, so it shouldn't be taking part in the process of
setting up GRUB to access root device.
However, running grub-install reports error as volume group "system"
contains encrypted volume.
error: attempt to install to encrypted disk without cryptodisk
enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'.
Certainly we can enable GRUB_ENABLE_CRYPTODISK=y and move on, but that
is not always acceptable since the server may need to be booted unattended.
Additionally, typing passphrase for every system startup can be a big
hassle of which most users would like to avoid.
This patch solves the problem by returning exact physical volume, /dev/vda2,
rightly used by system-root from the example above, thus grub-install will
not error out because the excessive encrypted device to boot the root device
is not configured.
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Olav Reinert <seroton10@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When a file on ext4 is stored as sparse the data belonging to
zero-filled blocks is not written to storage and the extent map is
missing entries for these blocks. Such case can happen both for depth
0 extents (leafs) as well as higher-level tables.
Consider a scenario of a file which has a zero-filled beginning (e.g.
ISO image). In such case real data starts at block 8. If such a file is
stored using 2-level extent structure the extent list in the inode will
be depth 1 and will have an entry to a depth 0 (leaf) extent header for
blocks 8-n.
Unfortunately existing GRUB2 ext2 driver is only able to handle missing
entries in leaf extent tables, for which the grub_ext2_read_block()
function returns 0. In case the whole leaf extent list is missing for
a block the function fails with "invalid extent" error.
The fix for this problem relies on the grub_ext4_find_leaf() helper
function to distinguish two error cases: missing extent and error
walking through the extent tree. The existing error message is raised
only for the latter case, while for the missing leaf extent zero is
returned from grub_ext2_read_block() indicating a sparse block.
Signed-off-by: Krzysztof Nowicki <krzysztof.nowicki@nokia.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Open Hack'Ware was the only user. It added a lot of complexity.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Open Hack'Ware was an alternative firmware of powerpc under QEMU.
The last commit to any Open Hack'Ware repo I can find is from 2014 [1].
Open Hack'Ware was used for the QEMU "prep" machine type, which was
deprecated in QEMU in commit 54c86f5a4844 (hw/ppc: deprecate the
machine type 'prep', replaced by '40p') in QEMU v3.1, and had reportedly
been broken for years before without anyone noticing. Support was removed
in February 2020 by commit b2ce76a0730e (hw/ppc/prep: Remove the
deprecated "prep" machine and the OpenHackware BIOS).
Open Hack'Ware's limitations require some messy code in GRUB. This
complexity is not worth carrying any more.
Remove detection of Open Hack'Ware. We will clean up the feature flags
in following commits.
[1]: https://github.com/qemu/openhackware and
https://repo.or.cz/w/openhackware.git are QEMU submodules. They have
only small changes on top of OHW v0.4.1, which was imported into
QEMU SCM in 2010. I can't find anything resembling an official repo
any more.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This code was broken by commit 3f05d693 (malloc: Use overflow checking
primitives where we do complex allocations), which added overflow
checking in many areas. The problem here is that the changes update the
local variable sz, which was already in use and which was not updated
before the change. So the code using sz was getting a different value of
than it would have previously for the same UDF image. This causes the
logic getting the destination of the symlink to not realize that its
gotten the full destination, but keeps trying to read past the end of
the destination. The bytes after the end are generally NULL padding
bytes, but that's not a valid component type (ECMA-167 14.16.1.1). So
grub_udf_read_symlink() branches to error logic, returning NULL, instead
of the symlink destination path.
The result of this bug is that the UDF filesystem tests were failing in
the symlink test with the grub-fstest error message:
grub-fstest: error: cannot open `(loop0)/sym': invalid symlink.
This change stores the result of doubling sz in another local variable s,
so as not to modify sz. Also remove unnecessary grub_add(), which increased
the output by 1, presumably to account for a NULL byte. This isn't needed
because an output buffer of size twice sz is already guaranteed to be more
than enough to contain the path components converted to UTF-8. The value of
sz contains at least 4 bytes for the path component header (ECMA-167 14.16.1),
which means that 2 * 4 bytes are allocated but will not be used for UTF-8
characters, so the NULL byte is accounted for.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When generating grub.cfg using grub-mkconfig and the scripts 10_linux and
20_linux_xen there is no way to add kernel command line parameters _only_ to
the recovery entries generated.
This is needed to e.g. start a debug shell in installations using systemd
using the kernel command line parameter "systemd.debug-shell" or to recover
in a system with encrypted root in situations where the decryption of the
root filesystem per crypttab in the intiramfs image is broken and the recovery
entry should contain information how to decrypt the rootfs (cryptopts=).
This patch does not change the default behaviour of the GRUB if
GRUB_CMDLINE_LINUX_RECOVERY is not set.
If GRUB_CMDLINE_LINUX_RECOVERY is set and the generated recovery entry should
include the kernel parameter "single" the parameter must be explicitly included
in GRUB_CMDLINE_LINUX_RECOVERY.
As far as I know all credits for the idea and the initial implementation go to
Kyle Ranking of Purism.
Signed-off-by: Kyle Rankin <kyle.rankin@puri.sm>
Signed-off-by: Chris Vogel <chris@z9.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The gcc by default assumes executable stack is required if the source
object file doesn't have .note.GNU-stack section in place. If any of the
source objects doesn't incorporate the GNU-stack note, the resulting
program will have executable stack flag set in PT_GNU_STACK program
header to instruct program loader or kernel to set up the executable
stack when program loads to memory.
Usually the .note.GNU-stack section will be generated by gcc
automatically if it finds that executable stack is not required. However
it doesn't take care of generating .note.GNU-stack section for those
object files built from assembler sources. This leads to unnecessary
risk of security of exploiting the executable stack because those
assembler sources don't actually require stack to be executable to work.
The grub-emu and grub-emu-lite are found to flag stack as executable
revealed by execstack tool.
$ mkdir -p build-emu && cd build-emu
$ ../configure --with-platform=emu && make
$ execstack -q grub-core/grub-emu grub-core/grub-emu-lite
X grub-core/grub-emu
X grub-core/grub-emu-lite
This patch will add the missing GNU-stack note to the assembler source
used by both utilities, therefore the result doesn't count on gcc
default behavior and the executable stack is disabled.
$ execstack -q grub-core/grub-emu grub-core/grub-emu-lite
- grub-core/grub-emu
- grub-core/grub-emu-lite
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The test for the ability to decompress zisofs encoded files is supposed
to fail due to the lack of this ability in GRUB. But it fails early with
xorriso : FAILURE : -volid: Text too long (1650 > 32)
because "ziso9660" is not in the list of filesystems which accept at most
32 bytes in their FSLABEL. If this is fixed, the test returns false
success because the xorriso run does not produce any zisofs compressed
files. The problem is in the sequence of native xorriso commands used.
The command -set_filter_r applies only to the files which are already
inserted into the emerging ISO filesystem. In the current sequence no
files have been inserted yet by command -add when the last of two
-set_filter_r commands is executed. After this is corrected, xorriso
refuses to work because the global settings of command -zisofs can be
made only before command -set_filter_r has attached zisofs filters to
the data files in the emerging ISO. Further: A bug in xorriso causes
a false warning about FSLABEL being too long for Joliet. Shortcomings
of Joliet cause warnings about symbolic links. Such warnings might
distract from the actual reason why the test is expected to fail.
So, add "ziso9660" to the 32-byte FSLABEL list.
Fix the xorriso run to produce compressed files which for now cause
righteous failure of the test. Do this by removing a surplus group of
-set_filter_r and -zisofs commands, by moving the other such group
behind -add, and by swapping -set_filter_r and -zisofs.
Remove the -as mkisofs options which produce a Joliet filesystem tree.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This conforms to the behavior of the -s option of the Bash read command.
docs/grub: Document the -s option for the read command.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is primarily useful to do something like "loopback newdev (dev)8+" to
create a device that skips the first 4 KiB, which may contain a container
header, e.g. a non-standard RAID1 header, that GRUB does not recognize. This
would allow that container data to be potentially accessed up to the end of
container, which may be necessary for some layouts that store data at the
end. There is currently not a good way to programmatically get the number
of sectors on a disk to set the appropriate length of the blocklist.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It helps to avoid an error on distros which has only python3 binary:
./autogen.sh: line 20: python: command not found
Use python3 as the default as python2 is EOL since Jan 2020. However,
check also for python which is on most distros, if not all, python2
because code still works on python2.
Although it should not be needed keep the possibility to define PYTHON
variable.
For detection use "command -v" which is POSIX and supported on all
common shells (bash, zsh, dash, busybox sh, mksh) instead requiring
"which" as an extra dependency (usable on containers).
Update the INSTALL file too.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The bootstrap.conf uses patch, let's require it.
Better than multiple messages:
./bootstrap.conf: line 84: patch: command not found
Mention it also in the INSTALL file.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The iso9660_test fails if the effective locale is not UTF-8. This happens
because xorriso needs to convert file names and FSLABEL to UCS-2 when
preparing a Joliet tree. The grub-fs-tester obviously intends to use UTF-8
as character set, but xorriso assumes by default the result of nl_langinfo(3)
with item CODESET. So, override the result of nl_langinfo(CODESET) by options
of xorriso -as mkisofs.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Clang does not support -falign-jumps and only recently gained support
for -falign-loops. The -falign-jumps=1 should be tested beside
-fliang-loops=1 to avoid passing unrecognized options to the Clang:
clang-14: error: optimization flag '-falign-jumps=1' is not supported [-Werror,-Wignored-optimization-argument]
The -falign-functions=1 is supported by GCC 5.1.0/Clang 3.8.0. So, just
add the option unconditionally.
Signed-off-by: Fangrui Song <maskray@google.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GCC warns "cc1: warning: ‘-malign-loops’ is obsolete, use ‘-falign-loops’".
The Clang silently ignores -malign-{jumps,loops,functions}.
The preferred -falign-* forms have been supported since GCC 3.2. So, just
remove -malign-{jumps,loops,functions}.
Signed-off-by: Fangrui Song <maskray@google.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes.
This change extended grub_xfs_inode struct by 76 bytes but also changed
the computation of XFS_V2_INODE_SIZE and XFS_V3_INODE_SIZE. Prior this
commit, XFS_V2_INODE_SIZE was 100 bytes. After the commit it's 84 bytes
XFS_V2_INODE_SIZE becomes 16 bytes too small.
As a result, the data structures aren't properly aligned and the GRUB
generates "attempt to read or write outside of partition" errors when
trying to read the XFS filesystem:
GNU GRUB version 2.11
....
grub> set debug=efi,gpt,xfs
grub> insmod part_gpt
grub> ls (hd0,gpt1)/
partmap/gpt.c:93: Read a valid GPT header
partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
fs/xfs.c:931: Reading sb
fs/xfs.c:270: Validating superblock
fs/xfs.c:295: XFS v4 superblock detected
fs/xfs.c:962: Reading root ino 128
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:515: Reading inode (739521961424144223) - 344365866970255880, 3840
error: attempt to read or write outside of partition.
This commit change the XFS_V2_INODE_SIZE computation by subtracting 76
bytes instead of 92 bytes from the actual size of grub_xfs_inode struct.
This 76 bytes value comes from added members:
20 grub_uint8_t unused5
1 grub_uint64_t flags2
48 grub_uint8_t unused6
This patch explicitly splits the v2 and v3 parts of the structure.
The unused4 is still ending of the v2 structures and the v3 starts
at unused5. Thanks to this we will avoid future corruptions of v2
or v3 inodes.
The XFS_V2_INODE_SIZE is returning to its expected size and the
filesystem is back to a readable state:
GNU GRUB version 2.11
....
grub> set debug=efi,gpt,xfs
grub> insmod part_gpt
grub> ls (hd0,gpt1)/
partmap/gpt.c:93: Read a valid GPT header
partmap/gpt.c:115: GPT entry 0: start=4096, length=1953125
fs/xfs.c:931: Reading sb
fs/xfs.c:270: Validating superblock
fs/xfs.c:295: XFS v4 superblock detected
fs/xfs.c:962: Reading root ino 128
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:931: Reading sb
fs/xfs.c:270: Validating superblock
fs/xfs.c:295: XFS v4 superblock detected
fs/xfs.c:962: Reading root ino 128
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:515: Reading inode (128) - 64, 0
fs/xfs.c:515: Reading inode (131) - 64, 768
efi/ fs/xfs.c:515: Reading inode (3145856) - 1464904, 0
grub2/ fs/xfs.c:515: Reading inode (132) - 64, 1024
grub/ fs/xfs.c:515: Reading inode (139) - 64, 2816
grub>
Fixes: 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
Signed-off-by: Erwan Velu <e.velu@criteo.com>
Tested-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Avoid a warning
lib/libgcrypt-grub/cipher/rijndael.c:229:9:
warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
229 | ;
| ^
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Avoid a warning
lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning:
comparison of integer expressions of different signedness:
‘int’ and ‘unsigned int’ [-Wsign-compare]
352 | for (i = 0; i < keylen; i++)
|
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the case that one passes a write mask with ":" the write_mask is
obtained from grub_strtoul() and then promptly overwritten by 0xffffffff
three lines later.
This appears to have been so since the initial version of setpci in 2009.
I'm surprised no one else has hit this issue in the past 12 years...
Signed-off-by: Wouter van Kesteren <woutershep@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The sysfs_partition_path() calls udevadm to resolve the sysfs path for
a block device. That can be accomplished by stating the device node
and using the major/minor to follow the symlinks in /sys/dev/block/.
This cuts the execution time of grub-mkconfig to somewhere near 55% on
system without LVM (which uses libdevmapper instead sysfs_partition_path()).
Remove udevadm call as it does not help us more than calling stat() directly.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
... to factor out fix for glibc 2.25 introduced in 7a5b301e3 (build: Use
AC_HEADER_MAJOR to find device macros).
Note: Once glibc 2.25 is old enough and this fix is not needed also
AC_HEADER_MAJOR in configure.ac should be removed.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except on
ieee1275 on x86, where it is 64MB.
There is a comment which purports to explain it:
/* If possible, we will avoid claiming heap above this address, because it
seems to cause relocation problems with OSes that link at 4 MiB */
This doesn't make a lot of sense when the constants are well above 4MB
already. It was not always this way. Prior to commit 7b5d0fe4440c
(Increase heap limit) in 2010, HEAP_MAX_SIZE and HEAP_MAX_ADDR were
indeed 4MB. However, when the constants were increased the comment was
left unchanged.
It's been over a decade. It doesn't seem like we have problems with
claims over 4MB on powerpc or x86 ieee1275. The SPARC does things
completely differently and never used the constant.
Drop the constant and the check.
The only use of HEAP_MIN_SIZE was to potentially override the
HEAP_MAX_ADDR check. It is now unused. Remove it too.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The "ide-drive" device was removed in QEMU 6.0. The "ide-hd" has been
available for more than 10 years now in QEMU. Thus there shouldn't be
any need for backwards compatible names.
Signed-off-by: Marius Bakke <marius@gnu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This incompat feature is used to denote that the filesystem stored its
metadata checksum seed in the superblock. This is used to allow tune2fs
changing the UUID on a mounted metdata_csum filesystem without having
to rewrite all the disk metadata. However, the GRUB doesn't use the
metadata checksum at all. So, it can just ignore this feature if it
is enabled. This is consistent with the GRUB filesystem code in general
which just does a best effort to access the filesystem's data.
The checksum seed incompat feature has to be removed from the ignore
list if the support for metadata checksum verification is added to the
GRUB ext2 driver later.
Suggested-by: Eric Sandeen <esandeen@redhat.com>
Suggested-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The underlying type of 1ULL does not change across architectures but
grub_uint64_t does. This allows using the BF64_*CODE() macros as
arguments to format string functions that use the PRI* format string
macros that also vary with architecture.
Change the grub_error() call, where this was previously an issue and
temporarily fixed by casting and using a format string literal code,
to now use PRI* macros and remove casting.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Skip versions between 2.07 and 2.10 to avoid leading zeros in minor
version number. This way version parsing in scripts should be easier.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
