grub-shell-luks-tester only cleans up generated files when the test it
runs returns success. Sometimes tests are run that should fail. Add
a --xfail argument to grub-shell-luks-tester and pass it from
grub_cmd_cryptomount when invoking a test that is expected to fail.
Reported-by: Thomas Schmitt <scdbackup@gmx.net>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GRUB has the capability to search all the disks for a cryptodisk of a
given UUID. Use this instead of hardcoding which disk is the cryptodisk,
which can change when devices are added or removed, or potentially when
QEMU is upgraded. This can not be done for the detached header tests
because the header contains the UUID.
Also, capitalize comment lines for consistency.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Fix a regression where qemuopts was mistakenly defaulted to the empty
string. This prevents the sending of arbitrary QEMU options to tests,
which may be desirable for overriding the machine type. There was a
concern that allowing the tester to accept arbitrary options would add
headaches for another developer trying to diagnose why a test failed on
the testers machine because he could not be sure if any additional
options were passed to make the test fail. However, all the options are
recorded in the run.sh generated script, so this concern is unwarranted.
Fixes: 6d729ced70 (tests/util/grub-shell: Add $GRUB_QEMU_OPTS to run.sh to easily see unofficial QEMU arguments)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Like the GNU ls, first print a line with the directory path before printing
files in the directory, which will not have a directory component, but only
if there is more than one argument.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The modification time for paths to files was not being printed because
the grub_dirhook_info, which contains the mtime, was initialized to NULL.
Instead of calling print_file() directly, use fs->fs_dir() to call
print_file() with a properly filled in grub_dirhook_info. This has the
added benefit of reducing code complexity.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The commit 504058e8 (libtasn1: Compile into asn1 module) generates files
into the grub-core/lib/libtasn1-grub directory and commit 99cda678
(asn1_test: Test module for libtasn1) generates files into the
grub-core/tests/asn1/tests directory. Ignore these directories as they
are not under revision control.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Support for @lbracechar{} and @rbracechar{} was added in GNU Texinfo 5.0
but many older systems may have versions lower than this. Use @{ and @}
to support a wider range of GNU Texinfo versions.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The current Debian stable, now 12, has dropped the exfat-utils package
that the exfat filesystem test requires to run. There is an exfatprogs
package that replaces exfat-utils, though it is not a drop-in replacement
because mkfs.exfat has differing command line option names. Note, that
we're not yet switching to using the exfat kernel module because this
allows the testings on kernels that do not have the module.
Update mkfs.exfat usage to adhere to the different exfatprogs usage. Also,
the exfatprogs mkfs.exfat, following the exfat specification more closely,
only allows a maximum of 22 bytes of UTF-16 characters in the volume label
compared to 30 bytes from exfat-utils. So the exfat label test is updated
accordingly.
Update documentation to note that exfatprogs is now needed and also
exfat-fuse, which is needed do the fuse mount.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When $detached_header was set 1, $luksdiskfile was set to the LUKS header
file path with "${detached_header:-$luksfile}" appended, which evaluates
to "1". Fix this by using two statements to set $luksdiskfile. The first
sets it to the header file if $detached_header is set, otherwise leave it
unset. The second statement sets it to itself if it is already set,
otherwise it is set to $luksfile.
Fixes: a7b540e6e (tests: Add cryptomount functional test)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
First look for firmware files in the source directory and then, if not
found, look for them in locations where Debian installs them. Prefer to
use the unified firmware file and, if not found, use the pflash firmware
files split in to code and variables. By looking for files in the source
directory first, system firmware files can be overridden and it can be
ensured that the tests can be run regardless of the distro or where the
system firmware files are stored. If no firmware files are found, print
an error message and exit with error.
If a firmware VARS file is found, use it with snapshot mode enabled, which
makes the VARS writable to the virtual machine, but does not write back
the changes to the file. This allows using the readonly system VARS file
without copying it or using it in readonly mode, which causes the ARM
machine to fail. This also gives tests effectively their own ephemeral VARS
file that can be written to without causing side-effects for other tests.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to the OVMF whitepaper [1]:
IMPORTANT: Never pass OVMF.fd to qemu with the -bios option. That option
maps the firmware image as ROM into the guest's address space, and forces
OVMF to emulate non-volatile variables with a fallback driver that is
bound to have insufficient and confusing semantics.
Use the pflash interface instead. Currently the unified firmware file is
used, which contains both firmware code and variable sections. By enabling
snapshot on the pflash device, the firmware can be loaded in such a way
that variables can be written to without writing to the backing file.
Since pflash does no searching for firmware paths that are not absolute,
unlike the -bios option, also make firmware paths absolute. Additionally,
update the previous firmware paths or file names that did not correspond to
ones installed by Debian.
Use the q35 machine, instead of the default i440fx, for i386-efi because
the default machine type does not emulate a flash device, which is now
needed to load the firmware.
[1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Allow using GDB to debug a failing QEMU test. This output does not cause
issues for tests because it happens before the trim line, and so will be
ignored.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Having randomly generated bytes in the binary output breaks reproducible
builds. Since build timestamps are usually the source of irreproducibility
there is a standard which defines an environment variable SOURCE_DATE_EPOCH
to be used when set for build timestamps. According to the standard [1], the
value of SOURCE_DATE_EPOCH is a base-10 integer of the number of seconds
since the UNIX epoch. Currently, this is a 10 digit number that fits into
32-bits, but will not shortly after the year 2100. So to be future-proof
only use the least significant 32-bits. On 64-bit architectures, where the
canary is also 64-bits, there is an extra 32-bits that can be filled to
provide more entropy. The first byte is NUL to filter out string buffer
overflow attacks and the remaining 24-bits are set to static random bytes.
[1] https://reproducible-builds.org/specs/source-date-epoch
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Generating the canary at build time allows the canary to be different for
every build which could limit the effectiveness of certain exploits.
Fallback to the statically generated random bytes if /dev/urandom is not
readable, e.g. Windows.
On 32-bit architectures, which use a 32-bit canary, reduce the canary to
4 bytes with one byte being NUL to filter out string buffer overflow attacks.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The canary, __stack_chk_guard, is in the BSS and so will get initialized to
zero if it is not explicitly initialized. If the UEFI firmware does not
support the RNG protocol, then the canary will not be randomized and will
be zero. This seems like a possibly easier value to write by an attacker.
Initialize canary to static random bytes, so that it is still random when
there is no RNG protocol. Set at least one byte to NUL to protect against
string buffer overflow attacks [1]. Code that writes NUL terminated strings
will terminate when a NUL is encountered in the input byte stream. So the
attacker will not be able to forge the canary by including it in the input
stream without terminating the string operation and thus limiting the
stack corruption.
[1] https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In certain firmwares, e.g. OVMF, the RNG protocol is not enabled unless
there is an RNG device. When not enabled, GRUB fails to initialize the
stack guard with random bytes. For testing, this is not a big issue, but
there have been bugs found in the initialization. So turn this on for EFI
platforms to catch any regressions.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GCC is electing to instrument grub_efi_init() to give it stack smashing
protection when configuring with --enable-stack-protector on the x86_64-efi
target. In the function prologue, the canary at the top of the stack frame
is set to the value of the stack guard. And in the epilogue, the canary is
checked to verify if it is equal to the guard and if not to call the stack
check fail function. The issue is that grub_efi_init() sets up the guard
by initializing it with random bytes, if the firmware supports the RNG
protocol. So in its prologue the canary will be set with the value of the
uninitialized guard, likely NUL bytes. Then the guard is initialized, and
finally the epilogue checks the canary against the guard, which will almost
certainly be different. This causes the code path for a smashed stack to be
taken, causing the machine to print out a message that stack smashing was
detected, wait 5 seconds, and then reboot. Disable grub_efi_init()
instrumentation so there is no stack smashing false positive generated.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The sector size in bytes is added to each line and it is allowed to be
6 decimal digits long, which covers the most common cases of 512 and 4096
byte sectors with space for two additional digits as future-proofing. The
size allocation is updated to reflect this additional field. Also make
clearer the size allocation calculation.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use the return value of grub_snprintf() to move the string pointer forward,
instead of incrementing the string pointer iteratively until a NULL byte is
reached. Move the space out of the format string argument, a small
optimization, but also makes the spacing clearer. Also, use the new
PRIxGRUB_OFFSET instead of PRIuGRUB_UINT64_T to accurately reflect the
format string for this type.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A large enough argument to the --port option could cause a string buffer
to be not NULL terminated because grub_strncpy() does not guarantee NULL
termination if copied string is longer than max characters to copy.
Fixes: 712309eaae (term/serial: Use grub_strncpy() instead of grub_snprintf() when only copying string)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When grub-install is run with the verbose option, it will print a log
message indicating the grub-mkimage command and arguments used.
GRUB no longer calls the grub-mkimage binary internally, however the
command logged is a command that if run should effectively be what
grub-install used. However, as this has changed some of the newer
options have been incorrectly added so that the printed command fails
when run separately. This change makes the displayed command run as
intended.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is a preparatory patch to make the following patch less cluttered. The
only visible change made here is to not print extra spaces when either or
both --note or --disable-shim-lock are not given and to not print an extra
space at the end of the command. The latter is done by constructing the
trailing argument string with spaces in front of each argument rather than
trailing. The allocation of the argument string is made precise, which has
the benefit of saving a few bytes, but more importantly self-documenting
what the needed allocated bytes are. Also, unneeded braces are removed from
an if block.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The backtrace module is written assuming that the frame pointer is in %ebp.
By default, -Os optimization level is used, which enables the gcc option
-fomit-frame-pointer. This breaks the backtrace functionality. Enabling
this may cause an unnoticeable performance cost and virtually no size increase.
The backtrace command on x86_64 and probably i386 is broken due to the
above rationale. I've not verified, but presumably the backtrace that used
to be printed for an unhandled CPU exception is also broken. Do any distros
handle this?
Considering that, to my knowledge, no one has complained about this in the
over 13 years that -Os has been used, has this code actually been useful?
Is it worth disabling -fomit-frame-pointer? Though, I don't see much downside
right now in disabling it. Alternatively, we could disable/remove the
backtrace code. I think it would be nice to keep it and have it working.
Nowadays, presumably QEMU makes the GDB stub rarely used as I imagine most
are developing in a virtual machines. Also, the GDB stub does not work in UEFI.
So, if anyone is using it on real hardware, they are doing so on pretty old
machines. The lack of a GDB stub does not seem to be a pain point because
no one has got it working on UEFI.
This patch gets the backtrace command working on x86_64-efi in QEMU for me.
However, it hangs when run on my laptop. Not sure what's going on there.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It has been reported that makeinfo version 4.13a complains and returns
error when menus for chapter structuring commands are not present. It
is also known that newer makeinfos, such as version 6.7, will create
default menus when needed. Since the menu will be created regardless,
explicitly create it to support older makeinfo versions. This also
enables building to be successful when an older makeinfo is installed
because in that case info files are attempted to be generated with the
"all" target.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
The @xref command is meant to be used at the beginning of a sentence
because its expansion creates a "See " prefix on all output formats, and
on older makeinfo versions is strict about enforcing a "." or "," after
the command. The @ref command has no such restriction and is just the
link, which allows more control over output. This also fixes an issue
where there was a repeated "see" in the output.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Allow using the envvar GRUB_SHELL_LUKS_TIMEOUT to change the default
timeout. If not specified, use value of GRUB_SHELL_DEFAULT_TIMEOUT. And
if that is not specified, fallback to original 600s timeout.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This was causing the cryptomount command to return failure even though
the crypto device was successfully added. Of course, this meant that any
script using the return code would behave unexpectedly.
Fixes: 3cf2e848bc (disk/cryptodisk: Allows UUIDs to be compared in a dash-insensitive manner)
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Patrich Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To comply with C99 and POSIX standards, snprintf() should return the
number of bytes that would be written to the string (excluding the
terminating NUL byte) if the buffer size was big enough. Before this
change, the return value was the minimum of the standard return and the
length of the buffer. Rarely is the return value of grub_snprintf() or
grub_vsnprintf() used with current code, and the few places where it is
used do not need to be changed.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This test is meant to test output via various serial devices. Currently,
only the PCI serial device is tested.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
While here, move "-qemu=*" case to be next to the "--qemu-opts=*" case.
This causes no change in logic, but is more logically located.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In long list mode, if the file can not be opened, the file is not printed.
Instead, print the file but print the size as "????????????".
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For each non-directory path argument to the ls command, the full path was
being sent to the print functions, instead of the dirname. The long output
print function expected dirname to be the directory containing the file
and so could not open the file to get the file size because the generated
path was incorrect. This caused the output to be a blank line.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Specifically, return GRUB_ERR_BAD_FILE_TYPE because this is what is
expected by the ls command when it is given a path to a non-directory.
This fixes a bug where calling ls with a list of non-directory paths
outputs a blank line for each such argument.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The videoinfo command will initialize all non-active video adapters. Video
drivers tend to zero out the global framebuffer object on initialization.
This is not a problem when there is no active video adapter. However, when
there is, then outputting to the video adapter will cause a crash because
methods in the framebuffer object are reinitialized. For example, this
command sequence will cause a crash.
terminal_output --append gfxterm; videoinfo
When running in a QEMU headless with GRUB built for the x86_64-efi target,
the first command initializes the Bochs video adapter, which, among
other things, sets the set_page() member function. Then when videoinfo is
run, all non-Bochs video adapters will be initialized, each one wiping
the framebuffer and thus setting set_page to NULL. Soon after the videoinfo
command finishes there will be a call to grub_refresh(), which will
ultimately call the framebuffer's set_page which will be NULL and cause
a crash when called.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A list of improvements:
* Remove reference to "initial ramdisk" and replace with "initrd". This
then covers the case of ramdisk and ramfs, which is the usual method
with kernels 2.6 and newer.
* Add sentence with URL to initrd documentation Linux kernel.
* Add a section documenting how to have the initrd command generate
a new-style initrd via a specially crafted argument and include an example.
* Update initrd16 to refer to the initrd section and make note that
initrd16 is only on the pc platform.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to commit 0231d00082 (ACPI: SPCR: Make SPCR available to x86)
to the Linux kernel, "On x86, many systems have a valid SPCR table but the
table version is not 2 so the table version check must be a warning."
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The cat command should not be used to print binary data because it can
show bytes not in the binary data and not show bytes that are in the data,
which can lead to confusion. This happens because cat does some processing
of the data stream, namely trying to decode substrings as UTF-8.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This allows an invocation of grub-shell to set the value of debug regardless
of the global default environment variable GRUB_SHELL_DEFAULT_DEBUG.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When referring to initrd16 the link for initrd16 should be used, not a link
for initrd. Also, correct the spelling of additionally and add a comma after
it to correct its grammatical usage.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Using grub_strncpy() instead of grub_snprintf() is less overhead and
indicates clearly that the dest should be the same string as the source.
Also fix indentation.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These are currently always the same as PRI*GRUB_UINT64_T, but they may
not be in the future.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Python bytecode files, which end in .pyc, may be generated by the build
system as needed and should not go into the git repository.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When creating at runtime a newc initrd via arguments to initrd with "newc:"
prefixes, only emit a directory path record once. The original code
intended to do that by bailing out of emitting the record when the record
to be created matches an existing record. However, this does not happen
because grub_memcmp() is improperly checked.
Generating duplicate newc directory records does not cause any problems
because the Linux unpacker will skip it once it sees the directory already
exists. This fix saves a little processing and makes the generated newc
cpio archive a little smaller.
Fixes: 92750e4c60 (Add ability to generate newc additions on runtime.)
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
EFI status codes are of different classes depending on the first byte and
all error status codes defined in appendix D of the main spec start from
1 and have the high bit set. When printing as a uint, the decimal is a very
large number that needs have the high bit cleared get the spec error code.
This can be easily visually done by a human if the number is printed as hex.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Debugging GRUB can be tricky and require arcane knowledge. This will
help those unfamiliar with the process to get started debugging GRUB
with less effort.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
EFI firmware determines where to load the GRUB EFI at runtime, and so the
addresses of debug symbols are not known ahead of time. There is a command
defined in the gdb_grub script which will load the debug symbols at the
appropriate addresses, if given the application load address for GRUB.
So add a command named "gdbinfo" to allow the user to print this GDB command
string with the application load address on-demand. For the outputted GDB
command to have any effect when entered into a GDB session, GDB should have
been started with the script as an argument to the -x option or sourced into
an active GDB session before running the outputted command.
Documentation for the gdbinfo command is also added.
Co-developed-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI chainloader checks that a device path can be created for the $root
device before allowing chainloading to a given file. This is probably to
ensure that the given file can be accessed and loaded by the firmware.
However, since GRUB is loading the image itself, the firmware need not
be able to access the file location of the image. So remove this check.
Also, this fixes an issue where chainloading an image file on a location
that is accessible by the firmware, e.g. (hd0,1)/efi/boot.efi, would
fail when root is a location inaccessible by the firmware, e.g. memdisk.
Use GRUB_EFI_BYTES_TO_PAGES() instead of doing the calculation explicitly.
Add comment noting the section where the load options for the chainloaded
EFI application is constructed.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Extra arguments given to chainloader on EFI platforms will be sent to
the chainloaded application. Also, minor edit in the chainloading section
to note that chainloading can be a jump via the firmware and not
necessarily in real mode (which does not exist on some architectures).
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On some systems /usr/share/dict/american-english can be larger than the
available space on the filesystem being tested (e.g. vfat12a). This
causes a failure of the filesystem test and is not a real test failure.
Instead, use dd to copy at most 1 MiB of data to the filesystem, which is
enough for our purposes and will not fill any of the tested filesystems.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The menu entry commands now have their own section. Change the wording in
the section that they were in to reflect this.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The exfat-utils package is an older package complementing exfat-fuse, and
was the only exfat tools for a long time. The exfat filesystem testing code
was written with these tools in mind. A newer project exfatprogs appears to
be of better quality and functionality and was written to complement the
somewhat new exfat kernel module. Ideally we should be using the newer
exfatprogs. However, the command line interface for mkfs.exfat is different
between the two. So we can't use the exfatprogs tools until the test scripts
have been updated to account for this. Recommend installing exfat-utils
instead of exfatprogs for now.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In filesystem timestamp test, a check is done to verify that the timestamp
for a file as reported in Linux by the filesystem is within a few seconds
of the timestamp as reported by GRUB. This is done by grepping the output
of GRUB's ls command for the timestamp as reported by the filesystem in
Linux and for each of 3 seconds past that timestamp. All of these checks
except one redirect the output of grep to /dev/null. Fix this exception
to behave as the other checks.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Now that the gdb_grub script uses the Python API in GDB, a GDB with Python
support must be used. Note that this means a GDB with version greater than
7.0 must be used. This should not be an issue since that was released over
a decade ago. Also, the minimum version of Python must be 3.5, which was
released around 8 years ago.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add symbols for boot.image, disk.image, and lzma_decompress.image if the
target is i386-pc. This is only done for i386-pc because that is the only
target that uses the images. By loading the symbols for these images,
these images can be more easily debugged by allowing the setting of break-
points in that code and to see easily get the value of data symbols.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A new command, run_on_start, for things to do before GRUB starts executing.
Currently, this is setting up the loading of module symbols as they are
loaded and allowing user-defined script to be run if a command named
"onstart" exists.
On some platforms, notably x86, software breakpoints set in GDB before
the GRUB image is loaded will be cleared when the image is loaded. This
is because the breakpoints work by overwriting the memory of the break-
point location with a special instruction which when hit will cause the
debugger to stop execution. Just before execution is resumed by the
debugger, the original instruction bytes are put back. When a breakpoint
is set before the GRUB image is loaded, the special debugger instruction
will be written to memory and when the GRUB image is loaded by the
firmware, which has no knowledge of the debugger, the debugger instruction
is overwritten. To the GDB user, GDB will show the breakpoint as set, but
it will never be hit. Furthermore, GDB now becomes confused, such that
even deleting and re-setting the breakpoint after the GRUB image is loaded
will not allow for a working breakpoint.
To work around this, in run_on_start, first a watchpoint is set on _start,
which will be triggered when the firmware starts loading the GRUB image.
When the _start watchpoint is hit, the current breakpoints are saved to a
file and then deleted by GDB before they can be overwritten by the firmware
and confuse GDB. Then a temporary software breakpoint is set on _start,
which will get triggered when the firmware hands off to GRUB to execute. In
that breakpoint load the previously saved and deleted breakpoints now that
there is no worry of them getting overwritten by the firmware. This is
needed for runtime_load_module to work when it is run before the GRUB image
is loaded.
Note that watchpoints are generally types of hardware breakpoints on x86, so
its deleted as soon as it gets triggered so that a minimal set of hardware
breakpoints are used, allowing more for the user.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Many targets, such as EFI, load GRUB at addresses that are determined at
runtime. So the load addresses in kernel.exec will almost certainly be
wrong. Given the address of the start of the text segment, these
functions will tell GDB to load the symbols at the proper locations. It
is left up to the user to determine how to get the text address of the
loaded GRUB image.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Remove gmodule.pl and rewrite as a python in gdb_helper.py. This removes
Perl dependency for the GRUB GDB script, but adds Python as a dependency.
This is more desirable because Python is tightly integrated with GDB and
can do things not even available to GDB native scripting language. GDB must
be built with Python, however this is not a major limitation because every
major distro non-end-of-life versions build GDB with Python support. And GDB
has had support for Python since around 7.1-ish, which is about a decade.
This re-implementation has an added feature. If there is a user defined
command named "onload_<module name>", then that command will be executed
after the symbols for the specified module are loaded. When debugging a
module it can be desirable to set break points on code in the module.
This is difficult in GRUB because, at GDB start, the module is not loaded
and on EFI platforms its not known ahead of time where the module will
be loaded. So allow users to create an "onload_<modname>" command which
will be run when the module with name "modname" is loaded.
Another addition is a new convenience function is defined
$is_user_command(), which returns true if its string argument is
the name of a user-defined command.
A secondary benefit of these changes is that the script does not write
temporary files and has better error handling capabilities.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The gdb_grub script was originally meant to be run once when GDB first
starts up via the -x argument. So it runs commands unconditionally
assuming that the script has not been run before. Its nice to be able
to source the script again when developing the script to modify/add
commands. So only run the commands not defined in user-defined commands,
if a variable $runonce has already been set and when those commands have
been run to set $runonce.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are broadly two classes of targets to consider when loading symbols
for GRUB, targets that determine where to load GRUB at runtime
(dynamically positioned) and those that do not (statically positioned).
For statically positioned targets, symbol loading is determined at link
time, so nothing more needs to be known to load the symbols. For
dynamically positioned targets, such as EFI targets, at runtime symbols
should be offset by an amount that depends on where the runtime chose to
load GRUB.
It is important to not load symbols statically for dynamic targets
because then when subsequently loading the symbols correctly one must
take care to remove the existing static symbols, otherwise there will be
two sets of symbols and GDB seems to prefer the ones loaded first (i.e.
the static ones).
Use autoconf variables to generate a gdb_grub for a particular target,
which conditionally run startup code depending on if the target uses
static or dynamic loading.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
By moving this code into a function, it can be run re-utilized while gdb is
running, not just when loading the script. This will also be useful in
some following changes which will make a separate script path for targets
which statically vs dynamically position GRUB code.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This prevents load_all_modules from failing when called before any
modules have been loaded. Failures in GDB user-defined functions cause
any function which called them to also fail.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GDB logging is redirected to write .segments.tmp, which means that GDB
will wrap lines longer than what it thinks is the screen width
(typically 80 characters). When wrapping does occur it causes gmodule.pl
to misbehave. So disable line wrapping by using GDB's "with" command so
that its guaranteed to return the width to the previous value upon
command completion.
Also disable command tracing when dumping the module sections because that
output will go to .segments.tmp and thus cause gmodule.pl to misbehave.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
An error in any GDB command causes it to immediately abort with an error,
this includes any command that calls that command. This leads to an issue
in dump_module_sections where an error causes the command to exit without
turning off file redirection. The user then ends up with a GDB command
line where commands output nothing to the console.
Instead do the work of dump_module_sections in the command
dump_module_sections_helper and run the command using GDB's pipe command
which does the redirection and undoes the redirection when it finishes
regardless of any errors in the command.
Also, remove .segments.tmp file prior to loading modules in case one was
left from a previous run.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On EFI platforms where EFI calls do not require a wrapper (notably i386-efi
and arm64-efi), the func argument needs to be wrapped in parenthesis to
allow valid syntax when func is an expression which evaluates to a function
pointer. On EFI platforms that do need a wrapper, this was never an issue
because func is passed to the C function wrapper as an argument and thus
does not need parenthesis to be evaluated.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The functional test requires unicode.pf2 to run successfully, so
explicitly have the test return ERROR when its not found.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tests should be SKIP'd only when they do not apply to a particular target.
Hard errors are for when the test should run but can not be setup properly.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These are not added to grub-fs-tester because they are not generated and
none of the filesystem tests are run on these ISOs. The test is to run the
command "ls /" on the ISO, and a failure is determined if the command
times out, has non-zero return value or has any output.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
By using a shell variable that is set once by the expansion of an autoconf
variable, the resulting script is more readable.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When re-running a failed test, even the non-standard grub-shell QEMU
arguments should be preserved in the run.sh to more precisely replay
the failed test run.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Now it becomes trivial to re-run a test from the output in its working
directory. This also makes it easy to send a reproducible failing test to
the mailing list. This has allowed a refactor so that the duplicated code
to call QEMU has be condensed (e.g. the use of timeout and file descriptor
redirection). The run.sh script will pass any arguments given to QEMU.
This allows QEMU to be easily started in a state ready for GDB to be
attached.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This allows turning on shell tracing for grub-shell and grub-fs-tester
when its not practical or not possible to use command line arguments
(e.g. from "make check"). Turn on tracing when the envvar is an integer
greater than 1, since these can generate a lot of output. Since this
change uses the environment variables to set the default value for debug
in grub-shell, this allows enabling grub-shell's debug mode which will
preserve various generated output files that are helpful for debugging
tests.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_cmd_cryptomount make check test performs some functional testing
of cryptomount and by extension the underlying cryptodisk infrastructure.
A utility test script named grub-shell-luks-tester is created to handle the
complexities of the testing, making it simpler to add new test cases in
grub_cmd_cryptomount.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This allows test case scripts to use the appropriate halt command for
the built architecture to end execution early. Otherwise, test case
scripts have no way to know the appropriate mechanism for halting the
test case early.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Glenn Washburn