The ISO filesystem image iso9660_early_ce.iso exposes the unusual
situation that the Rock Ridge name entry of its only file is located
after a CE entry which points to the next continuation area.
The correct behavior is to read the Rock Ridge name and to only then
load the next continuation area. If GRUB performs this correctly, then
the name "RockRidgeName:x" will be read and reported by grub-fstest.
If GRUB wrongly performs the CE hop immediately when encountering the CE
entry, then the dull ISO 9660 name "rockridg" will not be overridden and
be put out by grub-fstest.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Tested-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The SUSP specs demand that the reading of the next SUSP area which is
depicted by a CE entry shall be delayed until reading of the current
SUSP area is completed. Up to now GRUB immediately ends reading of the
current area and loads the new one. So, buffer the parameters of a found
CE entry and perform checks and reading of new data only after the
reader loop has ended.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Tested-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch enables multiple options in Vec5 which are required and
solves the boot issues seen on some machines which are looking for
these specific options.
1. LPAR: Client program supports logical partitioning and
associated hcall()s.
2. SPLPAR: Client program supports the Shared
Processor LPAR Option.
3. DYN_RCON_MEM: Client program supports the
“ibm,dynamic-reconfiguration-memory” property and it may be
presented in the device tree.
4. LARGE_PAGES: Client supports pages larger than 4 KB.
5. DONATE_DCPU_CLS: Client supports donating dedicated processor cycles.
6. PCI_EXP: Client supports PCI Express implementations
utilizing Message Signaled Interrupts (MSIs).
7. CMOC: Enables the Cooperative Memory Over-commitment Option.
8. EXT_CMO: Enables the Extended Cooperative Memory Over-commit Option.
9. ASSOC_REF: Enables “ibm,associativity” and
“ibm,associativity-reference-points” properties.
10. AFFINITY: Enables Platform Resource Reassignment Notification.
11. NUMA: Supports NUMA Distance Lookup Table Option.
12. HOTPLUG_INTRPT: Supports Hotplug Interrupts.
13. HPT_RESIZE: Enable Hash Page Table Resize Option.
14. MAX_CPU: Defines maximum number of CPUs supported.
15. PFO_HWRNG: Supports Random Number Generator.
16. PFO_HW_COMP: Supports Compression Engine.
17. PFO_ENCRYPT: Supports Encryption Engine.
18. SUB_PROCESSORS: Supports Sub-Processors.
19. DY_MEM_V2: Client program supports the “ibm,dynamic-memory-v2” property in the
“ibm,dynamic-reconfiguration-memory” node and it may be presented in the device tree.
20. DRC_INFO: Client program supports the “ibm,drc-info” property definition and it may be
presented in the device tree.
Signed-off-by: Avnish Chouhan <avnish@linux.vnet.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch converts the plain numbers used in Vec5 properties to constants.
1. LPAR: Client program supports logical partitioning and
associated hcall()s.
2. SPLPAR: Client program supports the Shared
Processor LPAR Option.
3. CMO: Enables the Cooperative Memory Over-commitment Option.
4. MAX_CPU: Defines maximum number of CPUs supported.
Signed-off-by: Avnish Chouhan <avnish@linux.vnet.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Per systemctl(1), it "is asynchronous; it will return after the reboot
operation is enqueued, without waiting for it to complete". This differs
from kexec(8), which calls reboot(2) and therefore does not return.
When not using fallback, this confusingly results in:
error trying to perform 'systemctl kexec': 0
Aborted. Press any key to exit.
on screen for a bit, followed by successful kexec.
To reduce the likelihood of hitting this case, add a delay on successful
return. Ultimately, the systemd interface is racy: we can't avoid it
entirely unless we never fallback on success.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the tpm module is loaded, the verifier reads entire file into
memory, measures it and uses verified content as a backing buffer for
file accesses. However, this process may result in high memory
utilization for file operations, sometimes causing a system to run out
of memory which may finally lead to boot failure. To address this issue,
among others, the commit 887f98f0d (mm: Allow dynamically requesting
additional memory regions) have optimized memory management by
dynamically allocating heap space to maximize memory usage and reduce
threat of memory exhaustion. But in some cases problems may still arise,
e.g., when large ISO images are mounted using loopback or when dealing
with embedded systems with limited memory resources.
Unfortunately current implementation of the tpm module doesn't allow
elimination of the back buffer once it is loaded. Even if the TPM device
is not present or it has been explicitly disabled. This may unnecessary
allocate a lot memory. To solve this issue, a patch has been developed
to detect the TPM status at module load and skip verifier registration
if the device is missing or deactivated. This prevents allocation of
memory for the back buffer, avoiding wasting memory when no real measure
boot functionality is performed. Disabling the TPM device in the system
can reduce memory usage in the GRUB. It is useful in scenarios where
high memory utilization is a concern and measurements of loaded
artifacts are not necessary.
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.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>
RISC-V doesn't have to do anything very different from other architectures
to loader EFI stub linux kernel. As a result, just use the common linux
loader instead of defining a RISC-V specific linux loader.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arch specific image header details are not very useful as most of
the GRUB just looks at the PE/COFF spec parameters (PE32 magic and
header offset).
Remove the arch specific images headers and define a generic arch
headers that provide enough PE/COFF fields for the GRUB to parse
kernel images correctly.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
ARM64 linux loader code is written in such a way that it can be reused
across different architectures without much change. Move it to common
code so that RISC-V doesn't have to define a separate loader.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In grub-module-verifierXX.c, the function grub_module_verifyXX() performs an
initial check that the ELF section headers are within the module's size, but
doesn't check if the sections being accessed have contents that are within the
module's size. In particular, we need to check that sh_offset and sh_size are
less than the module's size. However, for some section header types we don't
need to make these checks. For the type SHT_NULL, the section header is marked
as inactive and the rest of the members within the section header have undefined
values, so we don't need to check for sh_offset or sh_size. In the case of the
type SHT_NOBITS, sh_offset has a conceptual offset which may be beyond the
module size. Also, this type's sh_size may have a non-zero size, but a section
of this type will take up no space in the module. This can all be checked in the
function get_shdr(), but in order to do so, the parameter module_size must be
added to functions so that the value of the module size can be used in
get_shdr() from grub_module_verifyXX().
Also, had to rework some for loops to ensure the index passed to get_shdr() is
within bounds.
Signed-off-by: Alec Brown <alec.r.brown@oracle.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>
This will let users know that the GDB session is using the GRUB gdb scripts.
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>
The gcc build has failed for 32-bit host (e.g. i386-emu and arm-emu)
due to mismatch between format specifier and data type.
../grub-core/osdep/devmapper/getroot.c: In function
'grub_util_pull_devmapper':
../grub-core/osdep/devmapper/getroot.c:265:75: error: format '%lu'
expects argument of type 'long unsigned int', but argument 2 has type
'int' [-Werror=format=]
../grub-core/osdep/devmapper/getroot.c:276:80: error: format '%lu'
expects argument of type 'long unsigned int', but argument 2 has type
'int' [-Werror=format=]
This patch fixes the problem by casting the type of calculated offset to
grub_size_t and use platform PRIuGRUB_SIZE as format specifier.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add support for trusted boot using a vTPM 2.0 on the IBM IEEE1275
PowerPC platform. With this patch grub now measures text and binary data
into the TPM's PCRs 8 and 9 in the same way as the x86_64 platform
does.
This patch requires Daniel Axtens's patches for claiming more memory.
Note: The tpm_init() function cannot be called from GRUB_MOD_INIT() since
it does not find the device nodes upon module initialization and
therefore the call to tpm_init() must be deferred to grub_tpm_measure().
For vTPM support to work on PowerVM, system driver levels 1010.30
or 1020.00 are required.
Note: Previous versions of firmware levels with the 2hash-ext-log
API call have a bug that, once this API call is invoked, has the
effect of disabling the vTPM driver under Linux causing an error
message to be displayed in the Linux kernel log. Those users will
have to update their machines to the firmware levels mentioned
above.
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
When working on memory, it's nice to be able to test your work.
Add a memtest module. When compiled with --enable-mm-debug, it exposes
3 commands:
* lsmem - print all allocations and free space in all regions
* lsfreemem - print free space in all regions
* stress_big_allocs - stress test large allocations:
- how much memory can we allocate in one chunk?
- how many 1MB chunks can we allocate?
- check that gap-filling works with a 1MB aligned 900kB alloc + a
100kB alloc.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
As a legacy support, if the vector 5 is not implemented, Power Hypervisor will
consider the max CPUs as 64 instead 256 currently supported during
client-architecture-support negotiation.
This patch implements the vector 5 and set the MAX CPUs to 256 while setting the
others values to 0 (default).
Signed-off-by: Diego Domingos <diegodo@linux.vnet.ibm.com>
Acked-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Avnish Chouhan <avnish@linux.vnet.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On powerpc-ieee1275, we are running out of memory trying to verify
anything. This is because:
- we have to load an entire file into memory to verify it. This is
difficult to change with appended signatures.
- We only have 32MB of heap.
- Distro kernels are now often around 30MB.
So we want to be able to claim more memory from OpenFirmware for our heap
at runtime.
There are some complications:
- The grub mm code isn't the only thing that will make claims on
memory from OpenFirmware:
* PFW/SLOF will have claimed some for their own use.
* The ieee1275 loader will try to find other bits of memory that we
haven't claimed to place the kernel and initrd when we go to boot.
* Once we load Linux, it will also try to claim memory. It claims
memory without any reference to /memory/available, it just starts
at min(top of RMO, 768MB) and works down. So we need to avoid this
area. See arch/powerpc/kernel/prom_init.c as of v5.11.
- The smallest amount of memory a ppc64 KVM guest can have is 256MB.
It doesn't work with distro kernels but can work with custom kernels.
We should maintain support for that. (ppc32 can boot with even less,
and we shouldn't break that either.)
- Even if a VM has more memory, the memory OpenFirmware makes available
as Real Memory Area can be restricted. Even with our CAS work, an LPAR
on a PowerVM box is likely to have only 512MB available to OpenFirmware
even if it has many gigabytes of memory allocated.
What should we do?
We don't know in advance how big the kernel and initrd are going to be,
which makes figuring out how much memory we can take a bit tricky.
To figure out how much memory we should leave unused, I looked at:
- an Ubuntu 20.04.1 ppc64le pseries KVM guest:
vmlinux: ~30MB
initrd: ~50MB
- a RHEL8.2 ppc64le pseries KVM guest:
vmlinux: ~30MB
initrd: ~30MB
So to give us a little wriggle room, I think we want to leave at least
128MB for the loader to put vmlinux and initrd in memory and leave Linux
with space to satisfy its early allocations.
Allow other space to be allocated at runtime.
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This was apparently "required by some firmware": commit dc9468500919
(2007-02-12 Hollis Blanchard <hollis@penguinppc.org>).
It's not clear what firmware that was, and what platform from 14 years ago
which exhibited the bug then is still both in use and buggy now.
It doesn't cause issues on qemu (mac99 or pseries) or under PFW for Power8.
I don't have access to old Mac hardware, but if anyone feels especially
strongly we can put it under some feature flag. I really want to disable
it under pseries because it will mess with region merging.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
On PowerVM, the first time we boot a Linux partition, we may only get
256MB of real memory area, even if the partition has more memory.
This isn't enough to reliably verify a kernel. Fortunately, the Power
Architecture Platform Reference (PAPR) defines a method we can call to ask
for more memory: the broad and powerful ibm,client-architecture-support
(CAS) method.
CAS can do an enormous amount of things on a PAPR platform: as well as
asking for memory, you can set the supported processor level, the interrupt
controller, hash vs radix mmu, and so on.
If:
- we are running under what we think is PowerVM (compatible property of /
begins with "IBM"), and
- the full amount of RMA is less than 512MB (as determined by the reg
property of /memory)
then call CAS as follows: (refer to the Linux on Power Architecture
Reference, LoPAR, which is public, at B.5.2.3):
- Use the "any" PVR value and supply 2 option vectors.
- Set option vector 1 (PowerPC Server Processor Architecture Level)
to "ignore".
- Set option vector 2 with default or Linux-like options, including a
min-rma-size of 512MB.
- Set option vector 3 to request Floating Point, VMX and Decimal Floating
point, but don't abort the boot if we can't get them.
- Set option vector 4 to request a minimum VP percentage to 1%, which is
what Linux requests, and is below the default of 10%. Without this,
some systems with very large or very small configurations fail to boot.
This will cause a CAS reboot and the partition will restart with 512MB
of RMA. Importantly, grub will notice the 512MB and not call CAS again.
Notes about the choices of parameters:
- A partition can be configured with only 256MB of memory, which would
mean this request couldn't be satisfied, but PFW refuses to load with
only 256MB of memory, so it's a bit moot. SLOF will run fine with 256MB,
but we will never call CAS under qemu/SLOF because /compatible won't
begin with "IBM".)
- unspecified CAS vectors take on default values. Some of these values
might restrict the ability of certain hardware configurations to boot.
This is why we need to specify the VP percentage in vector 4, which is
in turn why we need to specify vector 3.
Finally, we should have enough memory to verify a kernel, and we will
reach Linux. One of the first things Linux does while still running under
OpenFirmware is to call CAS with a much fuller set of options (including
asking for 512MB of memory). Linux includes a much more restrictive set of
PVR values and processor support levels, and this CAS invocation will likely
induce another reboot. On this reboot grub will again notice the higher RMA,
and not call CAS. We will get to Linux again, Linux will call CAS again, but
because the values are now set for Linux this will not induce another CAS
reboot and we will finally boot all the way to userspace.
On all subsequent boots, everything will be configured with 512MB of RMA,
so there will be no further CAS reboots from grub. (phyp is super sticky
with the RMA size - it persists even on cold boots. So if you've ever booted
Linux in a partition, you'll probably never have grub call CAS. It'll only
ever fire the first time a partition loads grub, or if you deliberately lower
the amount of memory your partition has below 512MB.)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Found during a test build on Debian/hurd-i386 with --disable-werror enabled:
In file included from grub-core/osdep/getroot.c:12:
grub-core/osdep/hurd/getroot.c: In function ‘grub_util_find_hurd_root_device’:
grub-core/osdep/hurd/getroot.c:126:13: error: unused variable ‘next’ [-Werror=unused-variable]
126 | char *next;
| ^~~~
grub-core/osdep/hurd/getroot.c:125:14: error: unused variable ‘size’ [-Werror=unused-variable]
125 | size_t size;
| ^~~~
Fixes: e981b0a24 (osdep/hurd/getroot: Use "part:" qualifier)
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
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 "addr" is used to request the memory with specific ranges but the real
loadable address come from the relocator. Thus, print the final retrieved
addresses, virtual and physical, for initrd.
On the occasion migrate to PRIxGRUB_ADDR and PRIxGRUB_SIZE format specifiers.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.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>
The disk sector size provided by sysfs file system considers the sector
size of 512 irrespective of disk sector size, thus causing the read by
the GRUB to an incorrect offset from what was originally intended.
Considering the 512 sector size of sysfs data the actual sector needs to
be modified corresponding to disk sector size.
Signed-off-by: Mukesh Kumar Chaurasiya <mchauras@linux.vnet.ibm.com>
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>
In the function send_dhcp_packet(), added an error check for the return
value of grub_netbuff_push().
Fixes: CID 404614
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We do a lot of math about heap growth in hot path of grub_memalign().
However, the result is only used if out of memory is encountered, which
is seldom.
This patch moves these calculations away from hot path. These
calculations are now only done if out of memory is encountered. This
change can also help compiler to optimize integer overflow checks away.
Signed-off-by: Zhang Boyang <zhangboyang.id@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When grub_memalign() encounters out-of-memory, it will try
grub_mm_add_region_fn() to request more memory from system firmware.
However, it doesn't preallocate memory space for future allocation
requests. In extreme cases, it requires one call to
grub_mm_add_region_fn() for each memory allocation request. This can
be very slow.
This patch introduces GRUB_MM_HEAP_GROW_EXTRA, the minimal heap growth
granularity. The new region size is now set to the bigger one of its
original value and GRUB_MM_HEAP_GROW_EXTRA. Thus, it will result in some
memory space preallocated if current allocations request is small.
The value of GRUB_MM_HEAP_GROW_EXTRA is set to 1MB. If this value is
smaller, the cost of small memory allocations will be higher. If this
value is larger, more memory will be wasted and it might cause
out-of-memory on machines with small amount of RAM.
Signed-off-by: Zhang Boyang <zhangboyang.id@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When grub_memalign() encounters out-of-memory, it will try
grub_mm_add_region_fn() to request more memory from system firmware.
However, the size passed to it doesn't take region management overhead
into account. Adding a memory area of "size" bytes may result in a heap
region of less than "size" bytes really available. Thus, the new region
may not be adequate for current allocation request, confusing
out-of-memory handling code.
This patch introduces GRUB_MM_MGMT_OVERHEAD to address the region
management overhead (e.g. metadata, padding). The value of this new
constant must be large enough to make sure grub_memalign(align, size)
always succeeds after a successful call to
grub_mm_init_region(addr, size + align + GRUB_MM_MGMT_OVERHEAD),
for any given addr and size (assuming no integer overflow).
The size passed to grub_mm_add_region_fn() is now correctly adjusted,
thus if grub_mm_add_region_fn() succeeded, current allocation request
can always succeed.
Signed-off-by: Zhang Boyang <zhangboyang.id@gmail.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>
If processing of a SUSP CE entry leads to a continuation area which
begins by entry CE or ST, then these entries were skipped without
interpretation. In case of CE this would lead to premature end of
processing the SUSP entries of the file. In case of ST this could
cause following non-SUSP bytes to be interpreted as SUSP entries.
Signed-off-by: Thomas Schmitt <scdbackup@gmx.net>
Tested-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
An SL entry consists of the entry info and the component area.
The entry info should take up 5 bytes instead of sizeof(*entry).
The area after the first 5 bytes is the component area. It is
incorrect to use the sizeof(*entry) to check the entry boundary.
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
